基于Spring Boot和微信小程序的定制旅游系统开发实战

1. 项目缘起与整体设计思路

1.1 这个系统到底解决什么问题

旅游线路定制，本质上就是解决一个“信息匹配”的问题。传统OTA平台上的旅游产品大多是固定团期、固定行程，用户只能在有限的选择里挑一个“差不多”的。但实际需求往往更加个性化：两人出行想住得舒服一点，带父母走行程不能太赶，公司团建需要包含拓展环节，这些需求在标准化产品里很难被满足。定制旅游服务一直存在，但线下沟通成本高、方案报价周期长，小旅行社根本接不住散客的定制需求。

这个项目要做的，就是把这个定制过程搬到微信小程序里。用户在小程序端提交需求，比如目的地、出行天数、预算区间、同行人群、偏好标签，后台基于线路库和景点数据自动生成推荐方案和报价，用户确认后直接在线支付。整个流程从原来的“微信聊三天、Excel传报价”压缩到几分钟完成。系统同时配套管理后台，运营人员可以维护线路素材、审核定制需求、调整行程方案、处理订单退款。

从技术选型看，这个组合非常典型：Spring Boot负责业务逻辑和数据持久化，微信小程序负责C端交互。微信小程序的好处不用多说，用户不用下载App，微信里扫码即用，而且天然具备微信支付的闭环能力。后端选择Spring Boot，生态成熟、招人好招、部署简单，对于一个需要快速上线的业务系统来说，这是最稳妥的选择。

1.2 技术选型时的关键取舍

项目核心栈我列一下：

• 后端：Spring Boot 2.7.x（具体版本见下文说明） + MyBatis-Plus + Redis + MySQL 8.0
• 小程序端：原生微信小程序 + WeUI组件库
• 鉴权方案：微信登录换取openid + JWT生成自定义登录态
• 支付：微信支付V3
• 部署：单机Docker Compose

这里有两个决定要重点解释。

第一，Spring Boot版本怎么选。如果你第一次搭项目，我强烈建议直接用Spring Boot 2.7.x配JDK 8，而不是一上来就追Spring Boot 3.x。不是说3.x不好，而是很多老牌第三方SDK的兼容适配还停留在2.x时代，尤其是微信支付SDK、一些短信服务商的SDK，在Spring Boot 3.x下用起来会遇到javax到jakarta的迁移问题。这个坑在热词里也很常见——“springboot版本太高”，十个人里有八个是踩了版本兼容的坑。如果你确实要用3.x，那就要接受JDK 17、jakarta命名空间迁移、部分starter需要找替代方案这些附加成本。做项目，稳定压倒一切。

第二，小程序端用原生还是跨端框架。热词里提到uni-app、HBuilderX、Taro这类跨端方案。跨端的好处是一套代码多端复用，但如果你只做微信小程序一个端，原生开发的调试链路更短、对微信API的封装最直接、出问题也更好排查。这个项目我用原生小程序开发，配合微信开发者工具，体验下来开发效率并不低，而且省去了一层框架的间接层。后续如果真要扩展支付宝小程序或者抖音小程序，再上跨端方案也不迟，前期不必为了想象的未来增加复杂度。

1.3 系统功能模块全景

整个系统按用户角色拆成两端，功能边界很清晰：

用户端（小程序）：

• 微信授权登录，自动获取用户基础信息
• 首页精品线路推荐，按城市、主题、价格筛选
• 定制需求提交：多步表单，选目的地、天数、预算、同行人、偏好
• 方案列表：系统自动匹配线路方案，展示行程明细和报价
• 订单流程：下单、支付、查看订单状态、申请退款
• 行程单查看：按天展示景点安排、交通方式、住宿信息
• 订单评价：出行后对线路和行程打分

管理端（后台系统）：

• 线路管理：维护基础线路、景点、住宿、交通资源
• 定制需求管理：审核用户提交的定制需求，分配运营人员跟进
• 方案管理：基于需求生成/调整行程方案，设定报价
• 订单管理：订单列表、状态流转、退款处理
• 数据看板：定制需求转化率、热门目的地排行、营收统计

这个功能划分基本覆盖了定制旅游业务的主链路，也兼顾了运营端的日常管理诉求。后面所有技术实现都是围绕这两个端推进的。

2. 数据库设计与核心模型拆解

2.1 核心表结构设计

数据模型是整个系统的地基。定制旅游业务跟标准旅游产品不一样，订单要跟“需求”和“方案”两层数据关联：用户先提需求，系统再出方案。如果表结构设计不合理，后面接支付、做统计都会很痛苦。

我直接把核心表拆开讲（以下字段为简化后的核心版本，满足业务主流程没问题）：

用户表 user_info：

线路表 route_line：

定制需求表 custom_demand：

出行方案表 route_plan：

订单表 order_info：

另外还要有景点表、酒店表、交通表之类的资源表，这些属于基础数据维护范畴，字段比较简单就不单独展开了。

2.2 为什么订单要跟方案关联而不是直接跟线路关联

这是我设计时反复权衡的一个点。标准旅游产品的订单直接关联线路ID就可以了，但定制业务的特殊性在于：用户下单买的是“为他量身定制的一套行程”，这套行程可能由多条线路的片段重组而来，也可能完全由运营人员手工编排。

所以我把“定制需求”作为业务起点，系统或运营人员基于需求生成“出行方案”，用户确认方案后生成“订单”。这样每个环节的数据都有据可查，后续如果要统计“哪个目的地的定制转化率最高”，直接按demand表和order表的关联来聚合，不需要从订单明细里反向解析。

2.3 行程明细的数据存储方案

行程明细我用了一个JSON字段存储，而不是单独建一张行程明细表。理由是：行程明细的结构会随着方案类型变化，比如一日游可能只需要景点和餐饮，五天四晚深度游需要每天的早中晚餐、住宿、交通、景点、自由活动时间。这种高度差异化的数据结构，用关系型表来硬建模会让查询和写入都很别扭。

JSON存储的好处是灵活，但代价是统计查询不方便。实际操作中我的处理方式是：行程细分明细只在方案详情页展示，不做按明细数据的多维统计，所以JSON完全够用。如果后续要做“哪些景点被选中的次数最多”这类分析，可以再单独建一张冗余表做统计，或者用定时任务把JSON解析后写入汇总表。这个思路对项目初期来说是最务实的。

3. 小程序端核心模块实现

3.1 登录态处理的完整链路

微信小程序的登录机制跟普通Web登录差别很大，这也是很多入门者最头疼的地方。整体链路是这样的：

步骤一：用户打开小程序，前端调用 wx.login 获取临时凭证 code。
步骤二：前端把 code 发送到后端接口 /api/user/wxLogin。
步骤三：后端拿到 code，调用微信接口 code2Session 换取 openid 和 session_key。
步骤四：后端用 openid 到 user_info 表查询用户是否存在，不存在则自动注册。
步骤五：后端生成JWT令牌返回给前端，前端存储到 storage，后续所有请求都带上。

这段链路里有一个很常见的坑：前后端联调时经常出现“小程序获取登录后的微信用户失败:wx1cb4398e1413dce7”这种报错。这个报错的基本排查思路是：

• appid和secret是否匹配：开发者工具里用的appid必须和后端配置的appid一致，尤其多人协作时经常有人用自己的测试号导致不一致。
• 后端请求code2Session是否成功：在日志里打印code2Session接口的返回值，如果返回errcode，根据错误码定位。常见的是40029（code无效），code是一次性的，用一次就废，不能重复使用。
• 域名白名单问题：如果前端配置了request域名，但code2Session请求是后端发起的，不受小程序域名限制，所以这一步主要检查后端到微信服务器的连通性。

3.2 用户头像昵称获取的适配处理

关于用户信息的获取，这个项目要特别注意：微信已经改版了用户授权逻辑，wx.getUserProfile 和 wx.getUserInfo 在2022年之后返回的信息越来越有限，头像和昵称默认变成灰色默认头像和“微信用户”。真正合规的做法是：

在小程序端用 open-type="chooseAvatar" 的按钮触发头像选择，昵称通过 input 组件设置 type="nickname" 让用户手动输入。这两个能力是微信官方推荐的替代方案，不需要弹窗授权，直接调起头像选择器或者调用微信键盘的昵称填充能力。

我在项目里是这么设计的：用户首次进入时自动登录（静默获取openid），但头像昵称不强制收集，只在用户下单时引导完善。这样既不破坏用户体验，也能拿到真实有效的用户信息。这个处理的完整流程是：用户点击头像区域 → 微信弹出头像选择器 → 拿到临时头像文件 → 上传到后端存储 → 返回URL更新用户信息；昵称同理，用 input 的 nickname 类型，用户点键盘上方的自动填充即可，不需要额外调接口。

3.3 定制需求表单的设计逻辑

定制需求提交是整个小程序端交互最复杂的模块。我把它拆成了一个三步表单：

第一步：选目的地和出行时间。目的地用搜索+热门城市快捷选择，出行时间用日期选择器，限制只能选未来三个月的日期。
第二步：选天数、预算和同行人。天数和预算用滑动选择器做成范围联动，比如天数选3天时，预算区间的建议范围会自动调整。
第三步：选偏好标签。标签分为“美食”“海景”“人文”“亲子”“购物”“徒步”等，最多选三个，超过三个给出提示。

这里有一个体验上的细节：很多人会把预算做成直接输入数字，但实测下来用户更愿意选区间而不是填具体金额。区间设置成几档，比如“人均1000-2000”“2000-3000”“3000-5000”“5000以上”，用户几乎没有思考成本。这个交互细节对定制转化率有很直接的正面影响。

3.4 支付流程对接要点

小程序端支付的核心是 wx.requestPayment。流程不复杂，但问题都藏在细节里：

前端调起支付前，需要后端先调用微信支付的统一下单接口，拿到 prepay_id，然后后端根据 prepay_id 生成5个参数（timeStamp、nonceStr、package、signType、paySign）返回给前端。前端拿到这5个参数调用 wx.requestPayment，微信弹出支付确认框。

paySign 的生成规则很容易踩坑：签名串是 appId、timeStamp、nonceStr、package（值是 prepay_id=xxx）、signType 这几个字段拼接后用商户私钥签名，顺序不能乱，编码格式必须是 UTF-8。我遇到过签名校验失败的情况，最后定位是 nonceStr 里带了特殊字符，换成纯字母数字组合就好了。

另一个高频坑是“真机测试(failed)net::err_connection_reset”。这个报错绝大多数情况下是网络层或者域名配置问题，跟业务代码无关。检查路径一般是三步：

• 微信公众平台后台的“开发管理-开发设置-服务器域名”里，request合法域名是否配置了后端的HTTPS域名。
• 后端域名是否备案，微信强制要求所有请求域名必须ICP备案，没备案的域名在真机上请求直接失败。
• 开发者工具里把“不校验合法域名”打开能调通，但真机必须走正规域名，这个没得商量。

4. Spring Boot服务端架构与关键接口设计

4.1 项目分层与目录结构

后端项目我按经典的三层架构来组织，controller-service-mapper，这个是Spring Boot项目最主流的分层方式。如果你打开热词里的“springboot项目”相关博文，会发现绝大多数生产项目都是这个结构，不要搞花活。

具体的包结构如下：

java复制com.travel.custom
├── controller        // 接口层，只做参数接收和结果封装
│   ├── UserController.java
│   ├── LineController.java
│   ├── DemandController.java
│   ├── PlanController.java
│   └── OrderController.java
├── service           // 业务层，核心逻辑都在这里
│   ├── UserService.java
│   ├── DemandService.java
│   ├── PlanService.java
│   └── OrderService.java
├── mapper            // MyBatis-Plus的Mapper层
├── entity            // 数据库实体类
├── dto               // 请求参数对象
├── vo                // 响应结果对象
├── config            // 配置类（Redis、拦截器、微信SDK等）
├── common            // 公共类（统一返回结果、异常处理、常量）
└── utils             // 工具类（JWT、日期等）

Controller层只做三件事：接收参数、调用Service、返回统一结果。业务逻辑全部下沉到Service层，这样每个接口的逻辑可以单独测试，也方便后续做服务拆分。统一返回结果我定义成 code、message、data 三个字段的通用结构，code 为 0 表示成功，非 0 表示业务错误，配合全局异常处理器，前端只需要看 code 就能判断请求结果。

4.2 登录接口的完整实现

用户登录接口是后端所有接口里最基础的，这里贴一下核心逻辑：

java复制@PostMapping("/api/user/wxLogin")
public Result<String> wxLogin(@RequestBody WxLoginDTO dto) {
    // 1. 调用微信 code2Session 接口获取 openid
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid="
            + appid + "&secret=" + secret
            + "&js_code=" + dto.getCode() + "&grant_type=authorization_code";
    String result = restTemplate.getForObject(url, String.class);
    JSONObject json = JSONObject.parseObject(result);
    
    String openid = json.getString("openid");
    if (StringUtils.isEmpty(openid)) {
        // 打印微信返回的errcode，方便定位
        log.error("wx login failed: {}", result);
        return Result.fail("登录失败，请重试");
    }
    
    // 2. 查询用户是否存在，不存在则注册
    User user = userMapper.selectOne(
        new LambdaQueryWrapper<User>().eq(User::getOpenid, openid));
    if (user == null) {
        user = new User();
        user.setOpenid(openid);
        user.setStatus(1);
        userMapper.insert(user);
    }
    
    // 3. 生成JWT
    String token = JwtUtil.generateToken(user.getId(), user.getOpenid());
    return Result.success(token);
}

这段代码逻辑不复杂，但有三个必须注意的细节。第一，code2Session接口返回的openid是核心数据，但session_key也不要忽略，后续如果要解密手机号，要用到session_key。这个项目的手机号绑定我用的是后续的getPhoneNumber能力，在需要绑定手机号的场景重新调用一次session_key获取即可。第二，code2Session调用是有频率限制的，如果出现大量用户同时登录，注意不要做无谓的重复调用。第三，JWT的密钥要放到配置中心或环境变量里，不要硬编码在代码中，这个老生常谈了但真的有人会犯。

4.3 定制推荐接口的匹配算法

定制推荐是整个系统最有业务价值的部分。用户提交完需求，系统怎么从线路库里匹配出合适的方案，这里我设计了一套基于标签打分和价格过滤的匹配策略，逻辑很直白：

第一步：硬性过滤。先根据目的地和出行天数过滤出候选线路。目的地必须精确匹配，天数允许误差1天（比如用户选4天，3天或5天的线路也可以进入候选池，因为定制方案允许在基础线路上扩展或裁剪）。

第二步：预算校验。把当前候选线路的起步价和用户的预算区间做比较。起步价高于预算上限的线路直接淘汰。

第三步：标签打分。把用户选的偏好标签和线路的tags字段做比对，命中一个加10分。同时根据同行人类型做加权，比如亲子出行时线路含“亲子”标签额外加5分，情侣出行时含“浪漫”“海景”标签额外加5分。

第四步：排序输出。按得分降序排列，得分相同的按价格从低到高排列，取前10条作为预选方案。

code复制
得分 = Σ(偏好标签命中分) + Σ(同行人加权分)

这套匹配算法我故意做得很轻量，没有上复杂的搜索引擎或者向量数据库。原因是定制业务的线路库规模通常只有几百条，用数据库查询加内存计算完全够用，没必要为这个量级引入额外组件。等线路库规模上到几万条再做全文检索，到时候上Elasticsearch也不迟。

4.4 方案生成与价格计算规则

方案生成有两种路径：全自动和半自动。全自动方案是系统根据匹配到的线路，直接套模板生成行程明细，根据线路基础价格加资源价格算出总报价。半自动方案是运营人员基于需求手工编排行程，在后台的操作界面里拖拽调整每天的顺序，系统根据编排结果自动汇总价格。

价格计算规则是这样的：

code复制总报价 = 基础线路价格 + 住宿价格 × 天数 + 交通价格 + 服务费

其中服务费率可以配置，默认是总价的5%。运营人员在后台可以单独调整某些资源的定价，比如果把标准酒店升级成五星酒店，系统会重新计算总报价。价格每次变更都留操作日志，避免用户下单后扯皮。

方案生成后状态置为“待确认”，小程序端会收到一条模板消息通知，提示“您的专属方案已生成”。这里有一个前置条件：用户必须在小程序里勾选了“允许接收消息通知”，否则模板消息下发的额度会被浪费。这个在页面引导时就要做好提示。

5. 关键业务逻辑与复杂场景落地

5.1 分布式订单号的生成方案

订单号是支付的唯一业务标识，生成方案的坑在于：如果直接拿数据库自增ID当订单号，不仅容易被外界推测当日订单量，而且在退款对账时和微信支付单号容易混淆。我的方案是：时间戳 + 用户ID后四位 + 随机数，拼成一个20位的纯数字订单号。

java复制public static String generateOrderNo(Long userId) {
    String time = new SimpleDateFormat("yyyyMMddHHmmss").format(new Date());
    String uid = String.format("%04d", userId % 10000);
    int random = (int) ((Math.random() * 9 + 1) * 1000);
    return time + uid + random;
}

这种格式的好处是：并发下重复概率极低（同一秒、同一用户、随机数有1000种可能），而且从订单号可以直接解析出下单时间，排查问题时很实用。

5.2 微信支付V3的接入与回调验签

支付模块是定制系统里最容易出问题的地方，接入微信支付V3我踩了不少坑，把关键点整理一下。

微信支付V3使用证书和APIv3密钥做签名，和前两代的方式完全不同。总结下来最重要的有以下几点：

• 商户证书：在商户平台下载API证书（apiclient_cert.p12 或 apiclient_key.pem），后端配置好证书路径和密钥。
• APIv3密钥：在商户平台自行设置的一串32位密钥，用于回调报文解密和微信支付平台证书管理。
• 回调通知：支付结果的回调地址必须是公网可访问的HTTPS地址，回调报文用 AES-256-GCM 加密，需要先用APIv3密钥解密才能拿到明文数据。
• 回调验签：必须校验微信支付平台证书的签名，防止伪造回调。这个步骤不能省，虽然代码量多了一点，但安全性完全不一样。

java复制// 支付回调处理核心逻辑（伪代码）
public void payNotify(HttpServletRequest request) {
    // 1. 读取请求体
    String body = readBody(request);
    // 2. 用APIv3密钥解密
    String plainText = decrypt(body);
    // 3. 解析为JSON
    JSONObject json = JSONObject.parseObject(plainText);
    // 4. 校验订单号和金额
    String orderNo = json.getString("out_trade_no");
    int totalFee = json.getInteger("amount").getInteger("total");
    // 5. 更新订单状态
    orderService.updatePayStatus(orderNo, totalFee);
    // 6. 返回成功标识
    return "{\"code\":\"SUCCESS\"}";
}

注意最后返回的"SUCCESS"必须是这个格式，微信要求回调返回成功标识，否则会认为回调失败，重试多次直到超时。

5.3 行程单生成的细节处理

行程单是用户付款后最关心的东西。我设计的方案是：生成的行程单按天展示，每天包含上午、下午、晚上三个时间段，每个时间段有对应的景点/活动/餐饮/住宿安排，这些数据都从方案JSON里解析渲染。

在实现行程单之前，我的方案plan_detail里存的是简化的JSON，包含每天的标题和概要；用户支付并确认出行后，运营人员会把完整的行程单补充完善，包含具体的集合时间、交通衔接说明、酒店名称和房间类型、导游联系方式等。前端通过 rich-text 组件渲染富文本格式的行程说明，保证排版风格统一。

行程单的状态分为“待完善”和“已发布”。支付成功后如果运营人员还没补齐完整信息，用户看到的是概要版，页面顶部有个明显提示“完整行程单正在准备中”；运营人员发布后，小程序通过 subscribeMessage 推送一条服务通知给用户。这个通知能力要在微信公众平台申请，并且用户需要主动订阅。我在支付成功页做了一个 wx.requestSubscribeMessage 的调用，让用户勾选“行程通知、订单状态通知”两个模板，实测订阅率能到70%以上。

5.4 多端联调与部署注意事项

这个项目涉及小程序端和服务端的联调，联调阶段的坑基本都集中在网络和配置上。

本地开发阶段，小程序开发者工具可以勾选“不校验合法域名”，这样后端用 http://localhost:8080 也能调通，代码层面不需要做任何环境判断。但发布到体验版或者正式版时，必须把请求地址改成正式的HTTPS域名，这个域名必须备案，必须配置SSL证书。

我在实际部署时用的是 Docker Compose 方式，把后端应用、MySQL、Redis 打包成三个容器，用 docker-compose.yml 统一编排。配置上把端口映射做好，数据库密码和密钥通过环境变量注入，不用硬编码。这套方案的好处是迁移服务器时只需要重新 docker-compose up 一下，所有依赖的中间件一起启动，比手动一个个装环境快一个量级。热词里提到的“springboot打包到docker desktop”在这个项目里也用到了——本地先在Docker Desktop里跑通镜像，再推到服务器或者直接导出镜像包，几步操作就能完成。

yaml复制version: "3.8"
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root123
      MYSQL_DATABASE: travel_custom
    ports:
      - "3306:3306"
    volumes:
      - mysql-data:/var/lib/mysql
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      SPRING_PROFILES_ACTIVE: prod
      DB_HOST: mysql
      REDIS_HOST: redis
    depends_on:
      - mysql
      - redis
volumes:
  mysql-data:

6. 实际踩坑记录与问题排查经验

6.1 微信登录失败的排查实录

这个项目开发过程中收到的最典型报错，就是热词里那个“小程序获取登录后的微信用户失败:wx1cb4398e1413dce7”。这个报错的格式是“失败:appid”，说明前端在调用微信接口时识别到了一个appid，但后端没有拿到对应的用户信息。我遇到的情况是：开发者在微信公众平台申请了新的小程序appid，但后端配置里的appid还是旧的。前端开发者工具里能看到当前的appid，但后端日志里显示调用code2Session用的是旧appid，两个不一致导致code2Session失败。

排查这个问题的过程很有代表性，我建议按这个顺序来：

• 第一步，打开微信开发者工具右上角的“详情”，确认当前小程序的AppID是多少。
• 第二步，查看后端配置文件里的 appid 和 secret 是多少。
• 第三步，如果两者不一致，修改后端的配置并重启服务。
• 第四步，如果一致但仍报错，检查后端调用 code2Session 接口的日志，看返回的errcode，常见的是 40013（appid无效）和 40125（secret无效）。

另外一个隐蔽的问题：如果多个人同时开发，开发者工具里登录的微信号如果不在该小程序的开发者列表里，也会出现授权异常。需要在微信公众平台后台的“成员管理”里把测试成员的微信号加进去。

6.2 真机调试网络异常的处理

“真机测试(failed)net::err_connection_reset”这个问题，我在项目上线前测试阶段遇到过好几轮。前面提到的域名配置问题就不重复了，这里说两个容易被忽略的细节。

第一，后端服务的HTTPS证书是否完整。有些云服务商的免费证书只有域名证书，没有证书链，导致部分手机系统在验证证书时直接中断连接。用 openssl s_client -connect 域名:443 可以检查证书链是否完整。

第二，小程序对请求超时时间有严格限制，默认是60秒。如果后端的某个接口耗时超过60秒，比如生成方案时依赖第三方地图API做路径规划，响应慢就会触发连接重置。解决方案是把耗时操作改成异步任务，先返回“处理中”状态，前端轮询获取结果。这个方案在定制需求审核场景特别实用——提交定制需求后先返回受理成功，后台运营人员确认后再推方案生成结果，用户的等待感知被转移到了通知上。

6.3 Spring Boot 3.x迁移的那些坑

前面提过“springboot版本太高”是热词里非常高频的话题，这里展开说说。如果你的项目是Spring Boot 2.x的旧项目，升级到3.x时至少会遇到下面这些改动：

• JDK版本：2.x支持JDK 8，但3.x强制要求JDK 17及以上。线上服务器的JDK升级是个不小的工作量。
• javax 到 jakarta 的命名空间替换：spring-boot-starter-web下的 javax.servlet.* 全部变成 jakarta.servlet.*，所有引用和配置文件里的类名都要改。
• Spring Security 的配置方式变化：WebSecurityConfigurerAdapter 废弃，改用 SecurityFilterChain Bean方式配置。
• 一些第三方starter没有3.x版本：比如某些老牌短信SDK、分布式事务组件、代码生成工具，如果依赖的三方库没跟上，项目就卡死在升级这一步。

所以我的建议是：新项目用2.7.x是最稳的组合，不要为了“新”而新。2.7.x在2023年底进入EOL，但对大多数业务项目来说，只要没有严重安全漏洞，2.7.x继续跑一两年完全没问题。如果真的要升级，先在分支里跑一遍全量测试，把第三方依赖清单逐一核对，再决定是否切换。

6.4 常见问题速查表

6.5 提升开发效率的几个配置建议

项目开发中，我把这些配置放进了一个独立的application.yml里，方便多环境切换：

yaml复制spring:
  profiles:
    active: dev
---
# application-dev.yml
server:
  port: 8080
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/travel_custom?useUnicode=true&characterEncoding=utf8&useSSL=false
    username: root
    password: root123
  redis:
    host: localhost
    port: 6379
wechat:
  appid: 你的appid
  secret: 你的secret
  pay:
    mch-id: 你的商户号
    api-v3-key: 你的APIv3密钥

开发环境用本地的MySQL和Redis，生产环境通过环境变量覆盖。热词里专门有“springboot配置”，说明很多人卡在配置上，我的心得是：把所有外部依赖的地址统一用变量管理，不要散落在代码各处，维护起来会轻松很多。除此之外，我还在工程里配了MyBatis-Plus的逻辑删除和自动填充，create_time、update_time这些字段不需要手动set，实体类上用@TableField注解加一个MetaObjectHandler全局处理器就可以搞定，省了一堆重复劳动。

7. 项目管理与后续扩展方向

7.1 单元测试与联调经验

这个项目里我写了不少单元测试，但重点不是覆盖率多少，而是要把核心链路测透。我的习惯是只对Service层写测试，重点覆盖三个场景：定制推荐的匹配打分是否合理、支付回调的状态流转是否幂等、退款场景下的订单状态是否正确。

幂等性这里特别提一下。支付回调可能因为网络原因被微信重复推送多次，如果回调处理不幂等，就会出现订单被重复更新、用户被重复通知的问题。我的处理是在回调处理入口加一个分布式锁，锁的key是订单号，同一订单的并发回调只允许一个线程进入，其他线程直接返回成功。同时订单状态字段有一个“已支付”的判断，如果已经处理过就不再重复更新。两层保护下来，即使微信重试十次也不会出问题。

7.2 系统后续可以怎么扩展

如果这个系统要继续在真实业务里跑，有几个明显的扩展方向。

第一，接入地图POI数据。目前方案里的景点、酒店信息都是人工维护，数据量大了以后维护成本很高。可以对接地图服务商的POI搜索接口，运营人员录入目的地时直接搜索并选择POI，系统自动拉取经纬度、地址、图片，省去手动录入的麻烦。热词里提到“h5能调用微信小程序当前经纬度不”，如果在行程单中集成一键导航，用户查看当天行程时可以直接跳到地图App导航到酒店或景点，体验会好很多。

第二，引入更智能的方案推荐。目前的标签打分匹配方式在数据量小的时候够用，但用户偏好积累多了以后，可以基于协同过滤给用户推荐其他人相似需求的方案，或者在用户重新提交定制需求时直接复用历史方案做微调，大幅缩短方案生成时间。

第三，增加分销和拼团玩法。定制旅游的客单价相对较高，如果能结合微信的社交链做“好友拼团定制”，或者让老用户分享定制方案给朋友并获得优惠券，获客成本会显著下降。这些商业层面的功能从系统架构上看，只是在现有订单和用户模型上扩展营销模块，前期设计时保留了一定的扩展余地。

我在实际落地这个系统的过程中，最大的体会有两点。一点是项目里所有复杂的业务逻辑都要先画清楚状态流转图再写代码，尤其是订单和支付的状态机，一旦上线再改状态流转逻辑会非常痛苦。另一点是前后端联调一定要尽早开始，不要等所有接口都写完再联调，每完成一个模块就约着联调一个模块，虽然前期看起来进度慢了，但后期的返工量会少非常多。定制旅游业务的特点是多变、重人工、强沟通，系统不可能完全取代人的判断，但可以把重复劳动降到最低，把决策支撑做到位。这是整个系统建设的核心思路，也是我认为这个项目最有价值的地方。