前阵子老同学找到我说他们旅行社准备上一套线上预订系统需求列得很干脆“小程序能订票、公众号里能下单、微信群转发的H5活动页也能直接买后台最好能改价格、排期、库存”。他最后补了一句“网上不是有很多JAVA旅游系统源码嘛你帮我看看靠不靠谱。”做了这么多年Java后端类似问题我接过不止一次所以这次我没急着下结论而是把市面上这类源码的结构、业务模型和多端适配逻辑整体捋了一遍。这篇文章就从“畅享旅游系统”这类Java旅游系统源码出发聊一聊一套支持小程序、公众号和H5的旅游系统背后到底需要解决哪些核心问题以及你在接手、二次开发、部署上线时会踩到哪些坑。无论你是打算选型的技术负责人还是准备拿源码练手的Java开发都应该能从里面读出一些比“能跑demo”更实在的东西。1. 先搞清楚一件事旅游系统不是套了电商模板就能交付的项目很多第一次接触旅游系统的人会下意识觉得这不就是“商品、购物车、订单、支付”四件套吗换个皮就行了。真实情况远没有这么简单。旅游行业的交易对象不是标准化的实物商品而是一系列“在特定时间、特定条件下才成立的出行服务”。这个本质差异会直接改变整个后端的建模方式。1.1 旅游业务的几个“非标”特征先说产品维度。一个旅游产品由“线路、出发日期、套餐类型、出行人数”共同决定。同样是“云南大理丽江6日游”7月1日出发和9月15日出发可能是两个完全不同的价格余位也不一样同一日期下成人价、儿童价、单房差可能又是完全不同的SKU。普通电商的SKU库存是个静态数字旅游系统的库存本质上是一张“日历表”。再说订单链路。实物电商用户付款后系统基本只需要推给仓库发货。旅游订单付款后还要经历“确认出行人信息、供应商二次确认、出团通知书发送、入园/上车核销、行程结束后的售后”等多个阶段。每个阶段的超时时间、取消规则、退款比例都不一样如果底层的订单状态设计得不够灵活后面每加一个业务需求都要动一次表结构那就很痛苦了。所以在看这套Java旅游系统源码时我首先不看页面好看不好看而是看两样东西一是日期库存怎么建表二是订单状态机怎么定义。这两块立住了系统才真正像个旅游系统立不住界面再花哨也只能当展示Demo用。1.2 为什么“小程序公众号H5”会成为标配需求很多旅游公司并不是只有一个获客入口。公众号用来做内容种草和品牌沉淀小程序承载日常预订和会员运营H5页面则主要投放在朋友圈广告、分销员分享、短信营销链接等场景。这三个入口如果各做一套系统光是账号打通和订单归集就能把运维逼疯。所以“一套服务端支撑三端”几乎是最合理的解法。这里也解释了为什么这类系统偏爱Java技术栈。旅游业务的交易金额通常比较大、售后周期长团队对稳定性要求高Java生态里的Spring Boot、MyBatis-Plus、Redis、MySQL这些组合在中小型项目中足够成熟无论是招聘人员还是找外包维护都比冷门技术栈更稳妥。2. 从源码工程结构看架构取舍一个后端怎么撑起三个用户端拿到源码第一件事不是急着启动而是先看工程目录。虽然每家写的源码风格不同但成熟的旅游系统通常都分成管理端和用户端两大块。2.1 后端模块的前后分离设计以我过手一遍的这套源码为例后端基本结构长这样com.changxiang ├── framework // 通用配置、拦截器、异常处理 ├── admin // 后台管理端接口模块 │ ├── controller │ ├── service │ └── mapper ├── api // 用户端接口模块供小程序/公众号/H5调用 │ ├── controller │ └── service ├── modules │ ├── product // 旅游产品、分类、线路、日历库存 │ ├── order // 订单主表、明细、出行人、状态流转 │ ├── pay // 微信支付、退款、回调 │ ├── marketing // 优惠券、积分、推广员 │ ├── member // 会员资料、收货地址、实名/出行人 │ └── notify // 短信、公众号模板消息、小程序订阅消息 └── common // 返回体、常量、工具类关键点在于用户端模块api是三个前端共用的而不是给小程序单独写一套Controller、给H5再写一套。这样做的好处非常明显业务逻辑只维护一份小程序端、公众号H5端、外部H5端调用的是同样的接口只是不同端在登录方式、支付调起参数上有所区别。2.2 框架选型背后的理由大多数这类Java系统会采用Spring Boot作为基础框架。版本通常是2.x或3.x配套MyBatis-Plus做数据库操作Redis存会话和缓存MySQL存业务数据。有些更完整的源码会把RuoYi这类后台脚手架作为管理端基础再在上层扩展业务模块。单纯从“快速交付”的角度这个组合确实能省不少事。我特别想提醒一点看到“支持小程序公众号H5”的描述不要幻想它是一套前后端彻底分离的微服务架构。绝大多数有实战价值的源码都是“单体内聚”的也就是一个Spring Boot应用同时承载管理端接口和用户端接口。单体应用不等于落后对于单景区、单旅行社每天几千到几万单的业务量单体后端配合MySQL读写分离和Redis缓存完全扛得住反而比盲目拆微服务节省大量部署和运维成本。2.3 管理后台与用户端的数据边界管理后台负责复杂的数据维护例如产品上架、日期价格设置、订单审核、优惠券发放、数据报表用户端只暴露可预订产品、下单、支付、查看订单等必要接口。这里有个我比较认可的实践即使是同一个业务表管理端和用户端的查询逻辑也应该分开。比如后台查看订单可以列表里带出支付单号、供应商、操作日志等内部数据用户端的订单详情则只应该包含用户下单时看到的信息、当前状态提示、退款进度。把“内部视角”和“用户视角”的数据结构混在一起是旅游系统二次开发时最常见的安全隐患。3. 账号打通才是这套多端系统的灵魂微信生态登录态设计很多开发者拿到类似源码第一反应是跑起来看看首页长什么样。但我一般会先打开登录相关的代码因为小程序、公众号、H5这三端的用户身份体系是截然不同的让三种入口的用户归并到同一个“会员账号”下是整个系统成立的前提。3.1 openid、unionid、手机号哪个才是真正的用户ID微信生态里的用户标识有三个容易混淆的概念。小程序端调用wx.login()后后端拿code去微信接口换回的openid每个小程序都不同公众号网页授权拿到的openid每个公众号也都不一样。也就是说同一个微信用户在小程序里和公众号里的openid是两个值。如果系统只拿openid做主键用户会分裂成两个账号。解决这个问题的标准方案是unionid。前提是小程序和公众号必须绑定在同一个微信开放平台账号下。用户只要在绑定过的任一应用里授权过后端就能通过接口数据关联到同一个unionid。因此成熟的旅游系统源码一定会保留unionid字段并且会把“首次登录自动注册再次登录通过unionid找回老账号”作为核心逻辑。很多人在测试环境只有小程序没有公众号导致这套逻辑测不全。等上了生产用户在公众号里下单后发现自己在小程序里买的优惠券、积分、订单记录全都不见了才回头查unionid配置浪费不少时间。3.2 三种端口的登录流程差异具体流程上三端差别很明显小程序是典型的静默登录前端wx.login()拿code请求后端/api/auth/wx-mini-login后端通过code2session接口拿openid和session_key再返回自定义token。公众号内嵌H5走的是OAuth2网页授权。如果只需要识别用户身份用snsapi_base静默授权即可用户几乎感觉不到跳转如果要拿到头像昵称才需要snsapi_userinfo弹出授权页。旅游业务中比较推荐先snsapi_base静默建档等用户真正下单需要实名信息时再引导填写因为现在微信对主动弹窗授权越来越敏感一上来就弹授权框的转化率往往很差。微信外的H5则根本没有微信code可用系统只能走“手机号短信验证码”注册登录。注意这并不意味着H5用户进不来很多旅游产品的浏览和下单其实不需要强登录等到支付阶段再让用户输手机号或微信扫码登录体验会更顺。3.3 后端如何统一管理会话状态看这类源码时重点关注它怎么管理登录态。现在很多项目喜欢直接把JWT塞给前端然后每个接口解析令牌。对于旅游系统我反而更建议用“Redis存储会话”的方式。原因很朴素旅游订单生命周期长又有大量运营人员需要后台代客下单、查看用户订单的场景后台希望随时能把某个用户踢下线或者强制延长VIP客户的会话时长。如果token越权逻辑在JWT里写死这些运维操作实现起来会绕一大圈。一个合格的登录拦截器应该长这样public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); LoginUser user tokenService.getLoginUser(token); if (user null) { throw new BusinessException(401, 登录已过期请重新登录); } UserContext.setCurrentUser(user); return true; } }这里的tokenService内部实现是查Redis而不是解签JWT。UserContext用线程变量保存当前登录人后续所有业务方法都能拿到UserId。这样设计后登录来源在小程序、公众号还是H5已经无关紧要后面接口层面只认token不需要频繁地判断来自哪个端。3.4 用户信息同步的一个隐藏细节很多人会忽略的是用户头像昵称的更新策略。小程序端可以拿着session_key解密出手机号或用户信息但解密手机号需要小程序前端先触发getPhoneNumber公众号授权则不一定能拿到最新头像。所以源码里用户表通常会拆成“基础账号表”和“第三方授权资料表”两张表账号表主键是自增userIdunionid作为唯一标识授权资料表存每个端的openid、头像、昵称。不同端登录后各自更新各自的资料再通过unionid归并到同一userId。这个设计简洁可靠后续万一小程序或公众号要换绑也不需要动主账号结构。4. 日历库存与订单状态机旅游交易链路的两块硬骨头如果只说框架和登录这篇文章和其他“源码介绍”就没区别了。真正能拉开差距的是旅游业务核心数据模型的设计。我还是坚持那句话看旅游系统源码先看这两块基本能判断写这套代码的人是不是真正做过旅游业务。4.1 日历库存表该怎么设计普通电商的商品表加库存字段就完事了。旅游系统不行。以“一日游”产品为例同一个产品每天都可以有自己的库存和价格因此存在一张与产品关联的“日期库存表”。常见的表结构类似CREATE TABLE travel_date_stock ( id bigint NOT NULL AUTO_INCREMENT, product_id bigint NOT NULL COMMENT 产品ID, sku_id bigint NOT NULL COMMENT 套餐/票型ID, travel_date date NOT NULL COMMENT 出游日期, total_stock int NOT NULL DEFAULT 0 COMMENT 总库存, stock int NOT NULL DEFAULT 0 COMMENT 剩余库存, price decimal(10,2) NOT NULL COMMENT 当天售价, child_price decimal(10,2) DEFAULT NULL COMMENT 儿童价, PRIMARY KEY (id), UNIQUE KEY uk_product_sku_date (sku_id, travel_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意那个唯一索引它保证了同一个套餐在同一天只有一条记录这是防止并发重复插入的关键。实际操作中库存扣减不能用“先查再减”的套路要使用条件更新原子扣减UPDATE travel_date_stock SET stock stock - #{num} WHERE sku_id #{skuId} AND travel_date #{travelDate} AND stock #{num}这个SQL执行后如果影响行数为1说明扣减成功影响行数为0说明余位不足或日期不存在。绕开事务里的分布式锁也不会超卖。不过这里有个值得细想的业务场景一个旅游线路通常包含“成人票”、“儿童票”等不同票型它们的库存可能是共享的比如一辆大巴总共49座成人票和儿童票共享这49个名额。如果系统为成人票和儿童票各建一条库存记录各自有50个库存就会出现超卖风险。成熟的源码会做“父SKU库存”或“产品级日期库存”的概念把基础库存挂在产品上票型只做价格差异和儿童占比限制。如果源码里只是简简单单给每个票型一个独立stock字段遇到真正的旅游团队项目时一定会在旺季出事。4.2 订单状态机的正确打开方式旅游订单的状态比实物电商多出一截至少要覆盖“待支付、已支付待确认、已确认待出行、出行中/已完成、退款中、已退款、已取消”这些核心节点。如果状态字段是简单的string乱写一通后面对账和售后会非常难做。一个规范的订单状态流转如下状态含义可操作行为CREATED已创建待支付支付、取消、超时关单PAID已支付待确认供应商确认、申请退款CONFIRMED已确认待出行出团通知、申请退款/改期TRAVELLING行程中核销/服务中COMPLETED已完成评价、申请售后REFUNDING退款处理中财务审核、原路退回REFUNDED已退款关闭订单CANCELLED已取消无状态机不是一个简单的“当前状态”字段还包括状态变更记录表order_status_log。每一笔订单从创建到完成每一步谁在什么时间把状态改成了什么都应该可追溯。这在处理客诉和财务对账时几乎是必需品。退款流程也值得多看两眼。旅游的非标准化决定了全额退款和部分退款会频繁发生出发前7天以上退款不扣费、3天前扣20%、当天不可退。这种阶梯退改规则在源码里通常是独立的一张refund_rule表而不是在代码里写一堆if else。如果看到哪套源码把退改规则写死在业务代码里趁早避开后期维护成本太高。4.3 超时订单处理与重复支付防护旅游系统里“锁座”和“锁价”是很敏感的操作。用户选择了某个出游日期的库存并进入支付页系统应当为这个订单短期占住余位比如15分钟超过未支付自动释放。这通常在订单表里用一个expire_time字段控制再配合一个定时任务扫单把状态为CREATED且超时的订单改成CANCELLED并把步骤4.1里的库存加回去。这里特别容易踩一个坑用户支付成功了但支付回调因为网络问题延迟到达此时定时任务判断“未支付”把订单取消了库存也释放了。然后回调来了系统一看订单已经取消是给用户退款还是把订单状态改回已支付两种做法都有瑕疵。最稳妥的方案是把“取消订单”动作判断为只有CREATED状态才能取消已支付回调进来时如果发现订单状态是CANCELLED必须触发自动退款并记录异常日志而不是静默忽略。处理这个情况的代码往往只有十几行但少了这十几行旺季退款工单就能堆满客服的桌面。5. 支付与消息通知三端差别最大、踩坑最多的地方登录解决了“用户是谁”的问题支付和消息通知则解决了“钱怎么收、服务怎么触达”的问题。这三块在微信生态里各有一套规则稍微混用就会线上翻车。5.1 支付请求的渠道差异旅游交易金额高支付稳定是命根子。源码里通常会把支付模块单独抽出来统一对外提供PayService.createOrder(orderId, channel)方法内部再按渠道分流。小程序支付场景必须在微信小程序环境内调起后端调用统一下单接口时使用小程序的appid和当前用户的openid拿到prepay_id后签名返回给前端前端用wx.requestPayment拉起支付。公众号H5的场景稍微复杂一点。如果H5页面运行在微信公众号内、使用了公众号OAuth登录那么支付可以沿用JSAPI支付但如果H5页面只是运行在普通浏览器里用户既没有openid也没有公众号环境就需要走微信支付的“H5支付”这时后端下单价会多传一个scene_info微信要求发起支付的页面域名必须在商户平台配置为H5支付域名。很多刚跑通源码的人会把小程序下单、公众号下单、H5下单全用同一个支付方法结果上线后出现“当前页面URL未注册”之类的报错。所以源码里查看订单表应有一个order_source字段来标明订单来源下单、支付、后续退款对账都要以这个字段为依据。支付回调处理也要仔细看。微信支付回调是异步的而且网络不稳定时微信会重试多次所以处理回调的接口必须具有天然幂等性判断支付单号是否已处理过已处理直接返回成功不再重复修改订单。同时回调验签绝对不能省一旦验签失败要记录下来并返回错误信息防止有人伪造回调把订单改成已支付。5.2 退款与对账的逻辑退款在旅游系统里是个高频操作用户申请退款、供应商确认、财务原路退回。微信支付的退款接口也有自己的异步结果通知因此代码里需要一张refund_record表记录退款单号、退款金额、原订单号、操作人、退款状态。退款不代表订单状态立刻变成REFUNDED而是要等微信退款回调确认。很多源码把退款处理得太简单直接在Controller里同步调用微信退款接口后立刻把订单改成退款成功一旦网络超时用户钱没收到、后台状态却是已退款后面全乱套。5.3 公众号模板消息与小程序的订阅消息下单成功后的出团通知、出发前一天提醒是旅游系统提升体验的重要环节。公众号端通常使用模板消息或订阅消息。模板消息有行业类目限制申请时产品类目要匹配现在微信把模板消息逐步收紧新注册的公众号更多使用“订阅消息”能力用户需要主动授权一次才能收到一条消息。系统设计上要预先规划好用户会在哪个节点授权用户完成支付后请求授权订阅“出团通知”是转化率最高也最不打扰人的做法。小程序端类似调用wx.requestSubscribeMessage让用户勾选订阅后端在出行前一天通过接口推送。需要特别注意的是订阅消息的一次授权只对应一次推送如果业务上可能推送多条比如先发订单确认、再发出团提醒用户需要授权该消息模板两次。源码里如果没有做“订阅授权次数管理”很容易出现用户下完单却没收到后续关键通知的情况。6. 从“能跑通的源码”到“稳定上线”部署与二次开发要过的几道关很多开发把源码在本地启动成功后就觉得万事大吉。但生产环境和本地开发完全是两码事尤其是牵涉微信生态时一堆配置项要一一核对。6.1 微信公众平台侧的配置清单一个最容易让新手崩溃的报错是“redirect_uri参数错误”。这通常不是代码逻辑问题而是公众号后台的“网页授权域名”没有配置或者配置的域名与代码里OAuth2回调地址不完全一致。注意这里的域名不要带协议头和路径必须是精确到域名的格式。小程序端调试时经常遇到“request合法域名不合法”。小程序的网络请求只能在开发设置-服务器域名里配置的域名下进行。开发模式可以勾选“不校验合法域名”但上线前一定要把https://api.xxx.com加入request合法域名如果涉及图片上传或文件下载还要分别配置uploadFile合法域名、downloadFile合法域名。H5页面里通常会加载产品图片、富文本详情里的外链图片这些域名也可能被小程序拦截源码里要通过后端代理或者图片转存让所有图片都走自己的CDN域名。微信支付商户平台还需要配置API密钥、证书API尤其是退款接口必须使用商户证书。很多源码只在配置项里写了API密钥退款证书没配好结果正常收款没问题一退款系统就报错。我拿到任何一套旅游系统源码都会第一时间检查配置中心里有没有apiclient_cert.p12或apiclient_key.pem的加载路径并在联调环境真实退款一笔。6.2 服务器端部署拓扑参考旅游系统前中期不需要上太复杂的云原生架构。一台2核4G的云服务器起步装好JDK、MySQL、Redis、Nginx跑一个Spring Boot应用完全够一个小旅行社使用。如果用户量起来了再按下面路径演进Nginx与后端分离静态H5站点的资源直接让Nginx处理图片、上行文件对象存储化MySQL开启慢查询日志给日期库存和订单状态查询补索引Redis独立到单独实例设置合理的过期策略同一套后端多实例部署时用Nginx做负载均衡。源码里的application.yml通常暴露了配置文件修改入口。上线前至少要把数据库密码、Redis密码、微信AppSecret等信息移到环境变量或配置中心不能直接明文放在配置文件里。这些私密信息一旦随着前端源码或Git仓库泄露会给系统带来巨大风险。6.3 二次开发前必做的事情最后给拿源码做二次开发的同学几条建议。第一先通读订单、库存、用户三张核心表和状态流转代码不要急着加功能。任何新需求最后都会落到这三张表上看懂了全局再做开发才不会把原设计毁掉。第二把时间字段和金额字段的格式化统一掉。旅游系统里大量涉及“出游日期”和“下单时间”如果不同接口返回的时间格式不统一小程序端的解析代码会被逼着写大量补丁。第三在一个独立分支上做配置改造同时保留一份“演示数据”的初始化脚本。很多人二次开发时因为手欠把后台的测试产品、测试订单全部删光后面测前端页面时一张图都没有又得从零录数据非常耽误时间。第四不要小看日志。支付回调、退款回调、定时任务、管理员的订单操作这些都需要完整的操作日志。线上出了问题没有日志基本上等于没有线索。很多旅游源码在这块是薄弱项二次开发时值得优先补强。我自己在跑这套系统时习惯给关键的支付、关单、改价操作都加上结构化日志里面记录userId、订单号、变更前后状态、请求参数和耗时。这么做可能一天会多几百MB日志但换来的是出问题时十分钟内定位问题比什么都值。如果你准备正式商用一套多端旅游系统也建议从接手第一天就建立起同样的习惯后面会省下无数互相扯皮的时间。