SpringBoot+微信小程序旅行业务管理系统实战：从架构设计到代码实现-AI智能范式网

SpringBoot+微信小程序旅行业务管理系统实战：从架构设计到代码实现

木-Star·2026-09-30·阅读 21 GEO检测（免费）

SpringBoot微信小程序旅行业务管理系统

|难度：普通|阅读约 42 分钟

1. 项目最简单的拆解：它到底要解决什么问题

先说结论：这一套“SpringBoot + 微信小程序”的旅行业务管理系统，本质上解决的是传统旅行社“线下一团乱”的问题。

传统旅行社的日常业务大概是这样的：顾客到店或打电话咨询，销售翻纸质线路表、用口述报价，订单靠手写登记，收款靠微信转账后记Excel。一个人一天接五六个客户，Excel能顶住；一旦线路超过几十条、订单超过几百条，管理员就彻底乱了。更麻烦的是游客端根本没有任何自助查询、在线预订的渠道，所有信息都靠电话确认，效率和体验都很差。

这套毕设系统的价值就在这里：它把旅行业务拆成“游客端——商家管理端——后端服务”三条主线，游客在小程序里看线路、下单、查订单、退改；管理员在PC后台维护线路、处理订单、管理景点、发布公告；后端用SpringBoot统一处理业务逻辑和数据存储。重点不是做了多少页面，而是把一套完整的交易闭环做通了：浏览→选品→下单→支付→核销→售后。

整个项目看似是“又一个管理系统”，但它的难点和含金量集中在三块：**一是角色权限和业务状态的设计，二是小程序端和后台之间的接口约定，三是订单这类高并发高频操作的事务与一致性处理。**这也是我在实际开发里踩坑最多、收获最大的地方。

这个项目适合谁参考？如果你正在做计算机毕业设计，或者刚接触SpringBoot和小程序两条技术栈，想找一个“前后端打通、业务闭环完整、能演示也能答辩”的选题，这套系统的思路可以直接套用。就算你的选题不是旅游，换成社区团购、校园服务、宠物店管理，架构和核心代码逻辑也是通用的。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 系统整体设计与功能模块划分

2.1 用户角色和需求分析

我接手这个项目的时候，第一件事不是写代码，而是把业务角色掰开揉碎列出来。旅行社智慧运营平台，至少涉及三类角色：

角色	使用端	核心需求
游客（普通用户）	微信小程序	浏览旅游线路、查看景点详情、在线下单、订单查询与退款
旅行社业务员（管理员）	PC管理后台	线路维护、订单审核、游客信息管理、公告发布
系统超级管理员	PC管理后台	账号管理、权限分配、数据统计、基础配置

很多毕业设计做不好，问题就出在这一步——把“管理员”当成一个人什么都管。实际业务里，业务员只需要管线路和订单，超级管理员才管账号和权限。如果不做角色区分，后面的数据权限写起来会非常痛苦，演示的时候也不够专业。

2.2 功能模块清单

我按“两端两后台”的思路落地了功能，这里直接列一张完整的清单，方便后面照着做：

小程序端（游客可见）

首页：轮播Banner、热门线路推荐、公告通知
线路模块：线路列表、关键词搜索、线路详情（行程、价格、余位）
景点模块：景点介绍、图文展示、地图定位入口
订单模块：生成订单、订单列表、订单详情、取消订单、退款申请
个人中心：微信登录、用户信息、我的收藏、意见反馈
特色功能：扫身份证自动填充游客信息

PC管理后台（管理员可见）

登录与权限：账号密码登录、JWT鉴权、角色权限
数据看板：今日订单数、营收额、线路销量排行
线路管理：新增/编辑/上架/下架线路，库存余位管理
订单管理：订单列表、状态流转、退款审核
景点管理：景点增删改查、图片上传
公告管理：公告发布与展示
会员管理：用户列表、禁用/启用

这套模块划分的好处是：每张表、每个页面都有明确的归属，前后端可以并行开发，答辩时也能按模块一个一个讲清楚。

3. 技术选型与架构设计，为什么是SpringBoot + 微信小程序

3.1 选型的真实原因

很多同学纠结用什么框架，其实答案很现实：选SpringBoot不是因为它最先进，而是因为它最稳、资料最多、生态最完善。你做毕设最怕的不是功能复杂，而是遇到问题搜不到答案。

具体选型如下：

后端：SpringBoot 2.7.x + MyBatis-Plus + JWT + Redis
前端小程序：原生微信小程序 + WeUI组件风格 + ECharts（数据统计用）
PC后台：Vue 3 + Element Plus（如果时间紧，也可以用简单的Thymeleaf模板后台）
数据库：MySQL 8.0 + Redis（缓存热门线路、验证码、Token）
文件存储：MinIO（线路图片、景点图片统一管理）
接口文档：Knife4j（Swagger增强版，演示加分项）

这里有一个容易被忽视的点：SpringBoot版本别追新。我在开发中吃过亏，最开始时用了SpringBoot 3.2.x，结果MyBatis-Plus、一些第三方工具类的兼容性问题一堆，后来老老实实换回2.7.x，一下子干净了。毕业设计追求的是稳定，不是前沿。

3.2 整体架构分层

我把系统分成五个层次，每一层职责单一：

code复制小程序端 / PC后台端
        ↓ HTTP/HTTPS + JSON
Controller 层（接收参数、校验权限、返回统一结果）
        ↓
Service 层（业务逻辑、事务控制）
        ↓
Mapper 层（MyBatis-Plus 数据访问）
        ↓
MySQL + Redis + MinIO（数据与文件存储）

统一返回结果 Result<T> 是我一上来就写好的核心类，所有接口都返回同一结构：code、message、data。这样小程序端和Vue后台封装的请求工具极其简单，不用为每个接口做特殊处理。这个习惯强烈建议大家养成，后面联调能省一半时间。

3.3 数据库设计的关键思路

数据库是这个项目的灵魂，表设计错了，后面写代码全是补丁。我设计了11张核心表，这里挑最关键的几张说：

用户表 t_user

openid：微信用户唯一标识，索引必须加
nickname、avatar：用户基本信息
phone：手机号
status：账号状态（0正常 1禁用）

线路表 t_travel_line

title：线路名称
cover_img：封面图URL（MinIO生成的地址）
route_type：线路类型（0国内 1出境 2周边）
price：销售价
original_price：划线价
stock：总库存
remain：剩余余位
status：线路状态（0草稿 1上架 2下架）
description：图文详情（富文本）

这里特别要注意 stock 和 remain 分开存，下单扣的是 remain，补货或者售罄处理的是 stock，千万别混成一个字段。

订单表 t_order

order_no：订单编号（雪花算法生成）
user_id：下单用户
line_id：线路ID
quantity：出游人数
total_amount：订单金额
contact_name、contact_phone：联系人信息
tourist_list：出行人列表（JSON字符串）
status：订单状态（0待支付 1已支付 2已取消 3已退款 4已完成）

订单表是全系统最重要的表，状态流转一定要提前设计好，否则退款、取消这些功能会让你改到崩溃。我的状态机是这样的：待支付→支付成功→完成；待支付→取消；已支付→申请退款→退款成功。每一笔状态变化都在 t_order_log 里记录，方便追溯。

景点表、公告表、管理员表相对简单，这里不展开。最后记得所有表都加上 create_time、update_time 两个字段，MyBatis-Plus 的自动填充功能能省不少事。

4. SpringBoot 后端落地的关键实现

4.1 项目骨架和 Maven 构建

我创建的是标准单模块Maven项目，结构如下：

code复制travel-server/
├── src/main/java/com/example/travel/
│   ├── controller/         接收请求
│   ├── service/            业务逻辑
│   ├── mapper/             数据访问
│   ├── entity/             实体类
│   ├── config/             配置类（Redis、WebMvc、MinIO、Knife4j）
│   ├── common/             统一返回、异常处理、工具类
│   ├── security/           JWT拦截器、权限注解
│   └── TravelApplication.java
├── src/main/resources/
│   ├── application.yml
│   └── mapper/
└── pom.xml

pom.xml 的核心依赖我直接贴出来，版本都验证过稳定：

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
    <relativePath/>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>com.baomidou</groupId>
        <artifactId>mybatis-plus-boot-starter</artifactId>
        <version>3.5.5</version>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>8.0.33</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
        <groupId>com.auth0</groupId>
        <artifactId>java-jwt</artifactId>
        <version>4.4.0</version>
    </dependency>
    <dependency>
        <groupId>io.minio</groupId>
        <artifactId>minio</artifactId>
        <version>8.5.7</version>
    </dependency>
    <dependency>
        <groupId>com.github.xiaoymin</groupId>
        <artifactId>knife4j-openapi2-spring-boot-starter</artifactId>
        <version>4.4.0</version>
    </dependency>
    <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>fastjson2</artifactId>
        <version>2.0.46</version>
    </dependency>
</dependencies>

Maven构建这一步其实没那么难，但要注意JDK版本和SpringBoot版本必须匹配。SpringBoot 2.7.x对应JDK 8或11都行，我用的JDK 11，不与高版本的JDK 17产生兼容问题。打包命令就用最基础的：

bash复制mvn clean package -DskipTests

4.2 微信登录与 JWT 鉴权流程

小程序端用户不输入账号密码，只通过微信授权登录。完整流程分两步：

第一步：小程序端通过 wx.login() 获取临时 code，调用后端 /api/auth/login 接口。

第二步：后端用 code 调用微信接口，换回 openid 和 session_key，查询数据库。

如果用户首次登录，自动注册；如果已存在，直接生成JWT Token返回。

核心登录代码如下：

java复制@PostMapping("/login")
public Result<String> login(@RequestBody LoginDTO dto) {
    // 1. 用 code 换取 openid
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid
            + "&secret=" + secret
            + "&js_code=" + dto.getCode()
            + "&grant_type=authorization_code";
    JSONObject wxResp = HttpUtil.get(url, JSONObject.class);
    String openid = wxResp.getStr("openid");

    // 2. 查询或创建用户
    User user = userMapper.selectOne(new LambdaQueryWrapper<User>()
            .eq(User::getOpenid, openid));
    if (user == null) {
        user = new User();
        user.setOpenid(openid);
        user.setNickname("微信用户");
        user.setStatus(0);
        userMapper.insert(user);
    }

    // 3. 生成 JWT
    String token = JWT.create()
            .withClaim("userId", user.getId())
            .withExpiresAt(new Date(System.currentTimeMillis() + 7*24*3600*1000))
            .sign(Algorithm.HMAC256("travel-secret-key"));
    return Result.success(token);
}

这里有个坑必须先提醒：小程序端明明已经调了 wx.login()，但后端在本地联调时，微信接口往往因为域名未配置或调试模式限制返回错误。我当时的解决办法是先写一个本地模拟登录接口，前端传一个测试openid，后端直接按openid查表，联调通了再替换成真实微信接口。不要一开始就卡在微信接口的联调上，先把系统跑起来最重要。

4.3 核心接口实现：线路查询、下单与退款

线路分页查询我直接用MyBatis-Plus的 Page 对象，加上条件构造器即可：

java复制public Page<TravelLine> pageLines(int page, int size, String keyword, Integer type) {
    Page<TravelLine> p = new Page<>(page, size);
    LambdaQueryWrapper<TravelLine> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(TravelLine::getStatus, 1); // 只查上架状态
    wrapper.like(StringUtils.isNotBlank(keyword), TravelLine::getTitle, keyword);
    wrapper.eq(type != null, TravelLine::getRouteType, type);
    wrapper.orderByDesc(TravelLine::getCreateTime);
    return lineMapper.selectPage(p, wrapper);
}

下单接口是重头戏，必须处理并发和事务。游客下单时，要做三件事：校验线路存在且上架、校验余位足够、扣除余位并生成订单。这三步必须在一个 @Transactional 方法里完成，否则并发时会超卖。

java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(OrderDTO dto) {
    TravelLine line = lineMapper.selectById(dto.getLineId());
    if (line == null || line.getStatus() != 1) {
        throw new BizException("线路不存在或已下架");
    }
    Integer remain = line.getRemain();
    if (remain < dto.getQuantity()) {
        throw new BizException("余位不足，剩余" + remain + "位");
    }

    // 扣减余位
    int rows = lineMapper.deductRemain(line.getId(), dto.getQuantity());
    if (rows == 0) {
        throw new BizException("余位不足，请刷新后重试");
    }

    // 生成订单
    Order order = new Order();
    order.setOrderNo(IdWorker.getIdStr());
    order.setUserId(dto.getUserId());
    order.setLineId(line.getId());
    order.setQuantity(dto.getQuantity());
    order.setTotalAmount(line.getPrice() * dto.getQuantity());
    order.setStatus(0);
    orderMapper.insert(order);
    return order;
}

一定要用 deductRemain 这种带条件更新的SQL，而不是先查后改，因为查和改之间有时间差，并发场景会出问题：

sql复制UPDATE t_travel_line SET remain = remain - #{quantity}
WHERE id = #{lineId} AND remain >= #{quantity}

这一步是我整个项目里最有价值的经验，答辩时讲出来，老师会觉得你真的理解了业务。

退款接口我设计成“申请退款→管理员审核”两个阶段，没有让游客直接退款成功。因为旅游产品涉及资源预订，不是电商那种简单退款。后台审核时再调用支付平台的退款接口，毕设里直接用“模拟退款成功”即可。

4.4 MinIO 接入文件存储

项目里的线路封面图、景点图片不能直接塞数据库，也不能依赖外部图床，我选的是 MinIO 搭建本地对象存储。它的优势是部署简单、接口和阿里云OSS兼容，毕设里完全可以当“私有OSS”用。

接入步骤：

bash复制# 用 docker 快速起一个 MinIO
docker run -p 9000:9000 -p 9001:9001 \
  -e "MINIO_ROOT_USER=minioadmin" \
  -e "MINIO_ROOT_PASSWORD=minioadmin" \
  minio/minio server /data --console-address ":9001"

后端配置：

yaml复制minio:
  endpoint: http://localhost:9000
  access-key: minioadmin
  secret-key: minioadmin
  bucket: travel-images

上传接口核心代码：

java复制@PostMapping("/upload")
public Result<String> upload(@RequestParam("file") MultipartFile file) {
    String originalFilename = file.getOriginalFilename();
    String suffix = originalFilename.substring(originalFilename.lastIndexOf("."));
    String objectName = UUID.randomUUID().toString().replace("-", "") + suffix;
    minioClient.putObject(
        PutObjectArgs.builder()
            .bucket(bucketName)
            .object(objectName)
            .stream(file.getInputStream(), file.getSize(), -1)
            .contentType(file.getContentType())
            .build()
    );
    String url = endpoint + "/" + bucketName + "/" + objectName;
    return Result.success(url);
}

上传成功后，前端直接用返回的URL渲染图片。这里有一个细节：MinIO默认生成的URL如果是 http://localhost:9000，小程序真机是无法访问的，因为手机访问不到你电脑的localhost。联调时要换成电脑的局域网IP，比如 http://192.168.1.8:9000。我被这个问题坑了整整一个晚上。

5. 微信小程序端从零到能上手的落地过程

5.1 小程序端目录与公共请求封装

原生微信小程序虽然语法老一点，但胜在不需要额外构建工具，微信开发者工具打开就能跑，对毕设来说足够了。

页面目录组织：

code复制miniprogram/
├── pages/
│   ├── index/           首页
│   ├── lineList/        线路列表
│   ├── lineDetail/      线路详情
│   ├── orderList/       订单列表
│   ├── orderDetail/     订单详情
│   ├── user/            个人中心
│   └── scanIDCard/      扫身份证页面
├── utils/
│   ├── request.js       请求封装
│   ├── auth.js          登录态处理
│   └── util.js          工具函数
└── app.js / app.json / app.wxss

请求封装是所有小程序开发的第一步，我的 request.js 写法如下：

javascript复制const BASE_URL = 'http://192.168.1.8:8080/api';

function request(url, method, data) {
  return new Promise((resolve, reject) => {
    wx.request({
      url: BASE_URL + url,
      method: method || 'GET',
      data: data || {},
      header: {
        'Content-Type': 'application/json',
        'Authorization': wx.getStorageSync('token') || ''
      },
      success: (res) => {
        if (res.data.code === 200) {
          resolve(res.data.data);
        } else if (res.data.code === 401) {
          wx.removeStorageSync('token');
          wx.navigateTo({ url: '/pages/login/login' });
          reject(res.data);
        } else {
          wx.showToast({ title: res.data.message, icon: 'none' });
          reject(res.data);
        }
      },
      fail: (err) => {
        wx.showToast({ title: '网络异常', icon: 'none' });
        reject(err);
      }
    });
  });
}

module.exports = {
  get: (url, data) => request(url, 'GET', data),
  post: (url, data) => request(url, 'POST', data)
};

两个重点：一是请求里统一带 Authorization Header，这样后端拦截器才能识别登录态；二是统一处理401，Token过期时自动跳转登录页，不需要每个页面重复写。这里禁用“text”展示。

5.2 列表加载更多的两种实现方式

线路列表和订单列表都必须支持下拉刷新、触底加载。微信小程序没有现成的分页组件，我写了两次，经验如下：

第一版用的是 onReachBottom 触底加载：

javascript复制Page({
  data: {
    list: [],
    page: 1,
    size: 10,
    total: 0,
    loading: false,
    finished: false
  },
  onReachBottom() {
    if (this.data.finished) return;
    this.loadList();
  },
  async loadList() {
    if (this.data.loading) return;
    this.setData({ loading: true });
    const res = await request.get('/line/page', {
      page: this.data.page,
      size: this.data.size
    });
    const newList = this.data.page === 1 ? res.records : this.data.list.concat(res.records);
    this.setData({
      list: newList,
      total: res.total,
      page: this.data.page + 1,
      loading: false,
      finished: this.data.list.length >= res.total
    });
  }
})

关键点是：第一页和加载更多的数据拼接方式不同，必须加 loading 锁防止重复请求，必须用 finished 标记到底之后停止请求。很多同学做到最后列表越滑越卡，多半是没加这两个状态。

还有个容易被忽略的小坑：onReachBottom 在页面内容不足一屏时可能不触发，或反复触发。遇到这种情况，可以在初始页面数据不满一屏时，手动多调用一次加载逻辑，或者给页面容器加 min-height 撑出可滚动区域。

5.3 冒泡、滚动和顶部导航栏适配问题

微信小程序开发里，不同手机型号的状态栏高度不一样，直接写死 margin-top: 20px 会在刘海屏上露馅。正确做法是读取系统信息动态适配：

javascript复制const systemInfo = wx.getWindowInfo();
const navBarHeight = systemInfo.statusBarHeight + 44; // 胶囊按钮高度

在 app.js 里把高度存成全局变量，页面里用内联样式设置。如果你用了自定义导航栏，还要在 app.json 对应页面配置 "navigationStyle": "custom"。这个细节做得精致，小程序的整体质感会明显提升。

5.4 扫描身份证提取信息

搜索热词里有“微信小程序扫描身份证提取身份证号”，我在个人中心的“出行人管理”里做了一个简化版：调用 wx.scanCode 或摄像头拍照，然后用OCR SDK识别身份证正面的姓名和身份证号。如果不想接第三方收费OCR，也可以做成手动输入+正则校验身份证号格式：

javascript复制function checkIdCard(idCard) {
  const reg = /^[1-9]\d{5}(18|19|20)\d{2}((0[1-9])|(1[0-2]))(([0-2][1-9])|10|20|30|31)\d{3}[0-9Xx]$/;
  return reg.test(idCard);
}

这功能在答辩演示时非常加分，操作直观、有交互感，后台也能看到数据校验逻辑。

5.5 登录流程和页面权限控制

小程序端不强制先登录，游客可以先浏览线路，但下单时必须登录。实现方式是：在点击下单时判断本地有没有Token，没有就弹窗提示并跳转登录页。

登录页的逻辑是：调用 wx.login() 获取code→传给后端→拿回Token和用户信息→存入Storage→返回上一页。整个过程尽量在2秒内完成，不要让用户看到中间态。

这里还有个小细节：wx.login() 获取的code只有5分钟有效，且只能用一次。如果你在登录页重复调用，第二次可能拿到同一个code导致后端接口报错。正确做法是只在需要登录时调用一次，不要放到 onLoad 里重复执行。

6. 实际开发中的问题与排查技巧实录

6.1 SpringBoot版本太高带来的兼容性问题

这是整个项目最典型的坑。我初始新建项目时选了SpringBoot 3.2.1，本来觉得用新版是加分项，结果发现：

MyBatis-Plus直接启动报错，因为3.5.5及以上才勉强支持，老版本全崩
javax.servlet 换成 jakarta.servlet，很多老教程代码不通用
Knife4j的Swagger2兼容包在新版本下接口文档解析异常

排查思路很简单：直接用2.7.x重开项目，锁定JDK11。经过这次教训，我强烈建议所有毕设项目统一走“稳定优先”路线：SpringBoot 2.7.x + JDK 11 + MyBatis-Plus 3.5.x，不光兼容性好，网上随手能搜到的问题方案也最多。玩技术花活可以留到以后工作或自己折腾，毕业设计万万不要因为版本问题卡两周。

6.2 小程序请求不弹错误，但接口就是报404

这类问题出现时，前端 wx.request 始终返回404，而后端控制台没有任何日志。我当时的排查路径：

第一步检查后端是否启动、端口是否正确。第二步检查URL拼接是否正确，后端接口路径是 /api/line/page，但小程序 BASE_URL 是 http://192.168.1.8:8080/api，后面又拼了 /line/page，整体没问题才对。结果最后发现是后端Controller上有个类级别 @RequestMapping("line")，方法上又加了个 @RequestMapping("page")，但IDEA重构的时候把第一个RequestMapping里的 /api 漏掉了。

这类问题的通用排查法：先用浏览器直接访问接口URL，看能否返回数据。如果浏览器通了、小程序不通，大概率是域名/局域网IP问题或者Header缺失；如果浏览器也不通，问题一定在后端路由或参数定义上。

6.3 并发下单余位超卖

这个问题在本地单用户测试时完全看不出来，但答辩或演示时如果开两个设备同时下单，就可能复现：两条请求同时读到余位=1，各自判断“足够，下单”，最后生成两笔订单，余位变成-1。

解决方案上文已经写了，核心是SQL原子扣减：UPDATE ... SET remain = remain - #{quantity} WHERE id = #{id} AND remain >= #{quantity}，配合@Transactional。这些都是实战经验，不写进代码里，答辩被问到并发场景时也能讲得头头是道。

6.4 时间字段和金额精度问题

订单金额我用的是 BigDecimal 而不是 Double，这点别偷懒。数据库字段用 decimal(10,2) 存金额，用 datetime 存时间。JSON序列化时，LocalDateTime 默认格式不好看，我统一加了全局配置：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

如果不加时区，查询到的订单时间会差8小时，这在演示时虽然是“小问题”，但非常影响直观感受。别问我怎么知道的。

7. 前台小程序易疏漏的三个体验细节

如果只想让系统“看起来能用”，功能写完就够了。但想让它“看起来像个产品”，有几个细节值得打磨：

第一个是骨架屏和加载态。 小程序页面请求接口需要时间，纯白屏会让用户觉得卡死。我在线路列表页用一个简单的 wx:if 切换加载态，接口返回之前显示“加载中”，返回后渲染真实数据。不做复杂骨架屏，一行CSS加两三行WXML就能搞定，体验提升明显。

第二个是空数据态的引导。 订单列表为空时，别只显示一片空白，可以放一张插图和“暂无订单，去逛逛线路”按钮。我用最基础的条件渲染：

html复制<view wx:if="{{list.length === 0}}">
  <image src="/images/empty.png"></image>
  <text>暂无数据</text>
</view>

第三个是下拉刷新的体验。 我习惯在 app.json 里开启 "enablePullDownRefresh": true，配合自定义 onPullDownRefresh 重置页码并重新请求。但要注意关闭刷新动画：wx.stopPullDownRefresh() 如果不调用，页面会一直停在“下拉刷新中”的动画状态，很容易被忽略。

这些都是真实用户会注意到的点，也是编程能力之外的一种综合素质体现。毕设评分、面试展示都吃这一套。

8. 最后再聊聊这个项目的后续扩展方向

我个人在实际操作中最大的体会是：这类“业务管理系统”式毕设最大的价值不是某个炫酷技术，而是完整的数据流转和业务闭环。它教会了我从需求分析、数据库设计到前后端联调的全链路思考，这在课程设计里是学不到的。

如果时间充裕，建议在这个基础上再扩展两个方向：

一个是把PC后台的数据看板做深一点，接入ECharts统计每周订单趋势、线路销量Top10、用户增长曲线，视觉冲击力强，答辩时展示效果极佳。另一个是把支付环节换成真实微信支付沙箱环境，体验完整支付回调流程，虽然步骤多一点，但含金量能拉高不少。

另外，旅行业务管理系统这个选题天然适合“多端联动”的故事线：手机端、后台端、服务端三条线是同一个业务体系的三个切面。写文档和答辩PPT时，把这个故事讲清楚，比贴十张界面截图有用得多。

记得开发时把每一个你写过的接口截图留好，每一条业务逻辑的异常分支想清楚原因，每一个踩过的坑记录下来——它们都会变成答辩问答时的底气。开发这一路很累，但把系统从一张表设计成能跑起来的完整平台，那种成就感是真实且持久的。祝所有正在做类似项目的同学一次跑通，顺利答辩。