1. 毕业季旅游平台的项目定位与业务边界

每年六七月，大学的班级群和宿舍群里总会冒出大量"毕业旅行求组队""求推荐路线"的消息。毕业旅行和普通旅游的最大区别在于：这不是一次说走就走的个人行程，而是一个涉及多人统筹、预算分摊、时间协调的集体项目。有人管钱，有人管路线，有人管拍照，还有人负责对付那些"都可以"型选手——你问他想去哪，他说随便，你定了方案他又说不好。做过一次班级毕业旅行组织工作的人，应该都能体会这种"需求采集靠接龙、路线规划靠百度、费用核算靠备忘录"的原始状态。

这个项目的出发点，就是把上面这一堆乱糟糟的线下协作搬到一个Web平台上。系统的角色模型很清晰：普通学生用户能够浏览和报名毕业旅行路线、提交定制需求；班级或团体组织者可以创建团体行程、发起成员邀请、分摊费用并统一管理报名名单；旅游服务商或管理员则负责发布路线方案、处理定制订单、维护景点和酒店资源。整个系统背后有一个核心业务逻辑：它服务的是"一群人一起定制一次旅行"，而不是"一个人自己订一张票"。

这个定位差异直接影响了好几个设计决策。比如订单表必须区分"个人订单"和"团体订单"，团队订单的状态流转比个人订单复杂得多——有人缴费了有人还没缴，有人临时退出需要退款，有人想改行程方案。再比如路线推荐不能只按景点热度排序，还要考虑一个班级几十号人的集合地点、预算区间、出行天数。我当时做这个项目的时候，最深的体会是：业务边界想清楚了，表结构自然就出来了；业务边界含糊，后边所有代码都在打补丁。

这个项目适合两类人参考：一类是准备做毕业设计的Java方向学生，它涵盖的技术面比较均衡——Spring Boot、MyBatis、前端页面、权限管理、订单状态机、文件上传下载，足够撑起一个合格毕设的体量；另一类是工作中需要快速搭建一个中小型业务系统的人，可以重点看我后面讲到的订单状态设计和团体资金分摊思路。

2. 为什么选Spring Boot做底座：时序、依赖与工程结构

现在Spring Boot几乎成了Java Web项目的默认起点，但做这个项目时还是有几个人问我：为什么不用传统的SSM分层再加一堆XML配置？为什么不用现成的若依框架直接二开？

2.1 Spring Boot解决的核心痛点

传统SSM时代，一个项目从零搭建要经历：引入十多个Maven依赖、配置web.xml、配置spring-mvc.xml、配置mybatis-config.xml、配置数据源、处理静态资源映射……光是把环境跑起来就能耗掉一两天。而Spring Boot的自动配置机制把大部分重复劳动收掉了，它的核心逻辑可以理解为：classpath里有Spring MVC的依赖，我就自动帮你配好DispatcherServlet；有HikariCP和mysql驱动，我就自动帮你配好数据源。项目里只需要保留那些"我这套系统特有的配置"——比如自定义拦截器要注册、Redis连接参数要指定、文件上传大小要放开。

我用的是Spring Boot 2.x系列，Java 8，这个组合今天看起来不算最前沿，但作为框架学习项目非常稳。Spring Boot 3.x要求Java 17起步，换了javax到jakarta的包名，很多教程和案例还停留在老写法，对于毕设来说，如果导师给的参考代码、学校机房环境都偏向老一套，用3.x反而容易把自己卡住。我的建议是：如果不追求版本号好看，2.7.x是当下兼容性最好、踩坑信息最全的选择。

2.2 关于"要不要自己写前端"

这个平台的前端部分，我最终采用了服务端模板加少量原生JavaScript的方案。原因有三：第一，这是毕设，核心评分点在业务逻辑和技术栈覆盖，把大量精力花在Vue或React脚手架搭建上，性价比不高；第二，后端渲染对于权限控制、登录态校验这些场景天然友好，页面跳转时后端拦截器直接把关，不容易出现接口裸露的越权问题；第三，Thymeleaf和JSP这类模板技术的学习曲线平缓，改起来快，出现问题时脑子里能完整还原请求到响应的链路。

如果你前端能力比较强，用前后端分离加Vue会是个加分项，API文档写到Swagger里，答辩时展示接口测试截图也好看。但要注意一个现实问题：前后端分离意味着你在处理跨域、Token刷新、接口鉴权这些环节都要额外花时间，而且答辩时老师可能会盯着前端源码问双向绑定原理。我自己见过不少同学前后端分离做了两个月，最后卡在nginx部署环节，反而得不偿失。

2.3 我的标准工程结构清单

一个清晰的分层结构是这个项目后面不失控的关键。我的目录组织如下：

com.example.travel ├── controller // 控制层，只做参数接收与结果封装 │ ├── admin // 后台管理接口 │ ├── user // 用户端接口 │ └── order // 订单相关接口 ├── service // 业务层，核心逻辑全部写在这里 │ ├── impl // 接口实现 ├── mapper // MyBatis的Mapper接口 ├── entity // 数据库实体类（也可叫pojo/domain） ├── dto // 数据传输对象（接收前端参数） ├── vo // 视图对象（返回前端数据） ├── config // 配置类（拦截器、跨域、上传配置等） ├── common // 通用返回结果、异常处理、工具类 └── TravelApplication.java

这里我特别想强调一点：不要为了图省事把业务逻辑直接写在Controller里。我见过很多人写"一人端"项目，所有代码堆在Controller里两三行搞定一个方法，看起来很快，但等你写订单状态流转、退款逻辑、多人报名费用分摊这些复杂业务时，没有Service层兜底，代码会迅速膨胀到完全无法维护。一个实用的判断标准是：Controller方法里如果出现了if-else分支超过三层，或者需要连续调用三次以上mapper方法，这段逻辑就该下沉到Service。

3. 一站式定制的核心链路：从需求采集到订单落地

这个平台叫"一站式定制"，那它到底"定制"了什么？口头说一个概念很容易，但落到系统功能上，必须把定制流程拆成一条用户能感知到的主干链路。我最终把它拆成了四个环节：发起需求、智能推荐、方案确认、支付成团。

3.1 需求采集模块的业务模型

毕业旅行需求不是一张简单的"姓名+手机号+想去哪"表单。我的需求表（travel_demand）字段设计为：出行天数、出发城市、预算范围、偏好主题（海边/古镇/爬山/城市漫游）、成团人数、期望出行日期段、特殊要求备注。之所以把"出发城市"单独拎出来，是因为毕业旅行的集合出发地高度集中在学校所在城市，服务商在设计路线时必须从指定城市出发才能谈成团。

这个模块最容易忽略的是"成团人数"字段。个人可以一个人发起定制，但服务商能否接单取决于人数是否达到可盈利的成团线。所以我给系统加入了一个规则：需求提交后进入"待匹配"状态，后台服务商可以浏览需求池，符合条件则报价接单；如果需求在72小时内无人接单，状态自动变为"未匹配"，用户可以收到提示并调整参数重新提交。这个逻辑让定制服务不是一句空话，而是变成了系统里真实跑得通的状态流转。

3.2 路线推荐：权重评分而不是"猜你喜欢"

很多同学做推荐功能，一上来就写协同过滤，但毕业旅行平台的场景下，数据稀疏是硬伤——新用户没有行为历史，新路线没有评分数据，你拿什么算相似度？这个平台上我更倾向于做一个基于规则的路线匹配引擎。

具体做法是：给每条路线打上属性标签（主题、天数、预算档位、出发城市、人均价格），用户提交需求后，按以下规则计分：

• 主题匹配，权重50分
• 天数落在期望区间内，权重30分
• 预算差值最小，权重15分（价格比期望高太多直接淘汰）
• 近30天下单人数，权重5分

最后按总分排序推荐Top5。这个方案实现简单、解释性强，答辩的时候你能跟老师讲清楚每一分是怎么来的，比黑盒式推荐算法更容易获得认可。而且毕业旅行本来就带有很强的社交属性，用户更看重"跟谁去"而不是"平台推什么"，算法在这里的位置本来就应该轻一些。

3.3 团体行程的组装逻辑

团体项目和个人项目的根本区别在于：个人项目选好路线直接下单即可，团体项目则需要先有"团"，再往团里加人，最后才谈路线定制和费用。我在系统里设计了旅行团表（travel_group）和成员表（group_member），前者存团长ID、成团人数上限、当前状态（招募中/定制中/已成团/已出行/已完成），后者记录每个成员的报名状态和缴费状态。

这里有个细节值得展开：团体报名是允许"部分成员先报名、其他人后续加入"的，所以成员表里必须有个独立的报名字段，而不是用订单状态去隐式推断。我把每个成员的参与状态做成独立枚举：待确认、已确认、已缴费、已退款、已退出。这样团长看到的数据就是一张"谁还没缴费"列表，系统的催缴通知可以根据这张表精准发送到人，而不是群发全团造成困惑。

3.4 订单状态机与实际金额计算

订单表我把状态设计成：待付款（PENDING）、已付款（PAID）、定制中（CUSTOMIZING）、待出行（UPCOMING）、已完成（COMPLETED）、已取消（CANCELLED）、已退款（REFUNDED）。后端不是用一堆散落的if判断处理这些状态的，而是抽出了一个状态机工具类，统一维护状态流转的合法性：

/** * 订单状态流转校验 * key: 当前状态, value: 允许流转到的目标状态集合 */ private static final Map<OrderStatus, Set<OrderStatus>> TRANSITIONS = new EnumMap<>(OrderStatus.class); static { TRANSITIONS.put(OrderStatus.PENDING, EnumSet.of(OrderStatus.PAID, OrderStatus.CANCELLED)); TRANSITIONS.put(OrderStatus.PAID, EnumSet.of(OrderStatus.CUSTOMIZING, OrderStatus.REFUNDED)); TRANSITIONS.put(OrderStatus.CUSTOMIZING, EnumSet.of(OrderStatus.UPCOMING, OrderStatus.REFUNDED)); TRANSITIONS.put(OrderStatus.UPCOMING, EnumSet.of(OrderStatus.COMPLETED, OrderStatus.REFUNDED)); TRANSITIONS.put(OrderStatus.COMPLETED, EnumSet.of()); TRANSITIONS.put(OrderStatus.CANCELLED, EnumSet.of()); TRANSITIONS.put(OrderStatus.REFUNDED, EnumSet.of()); }

实际金额计算里坑最多的是团体单的"人均价格乘以人数"这个看似简单的逻辑。我遇到的情况是：路线方案调整了（比如把三星酒店升级成四星），服务商重新报价后，已经缴费的成员应该补差价，还没缴费的成员直接按新价格缴。这个在表结构上不能只改订单总价，需要一个报价变更记录表（quote_change_log）把每次改价前后的价格、影响成员、变更原因都记下来，否则结算对账时根本说不清。

4. 数据库设计：毕业季场景下的核心表结构与索引选择

数据库设计这个环节，可以说直接决定了项目后期是越写越顺还是越写越崩。我的经验是：先想清楚业务中最核心的实体是哪些，再把实体之间的关联关系理顺，最后才去画表、定字段。

4.1 九张核心表的组织逻辑

整个平台我最终沉淀出九张核心业务表，它们之间的关系如下：

• 用户表（user）：包含用户ID、昵称、手机号、密码、头像、角色标识，角色区分为普通用户、服务商、管理员，用整数字段存枚举值。密码存储用BCrypt加密，绝对不允许明文。
• 路线表（route）：路线名称、封面图片、主题标签、出发城市、目的地、天数、人均价格、库存名额、路线描述、状态（上架/下架）。
• 需求表（travel_demand）：用户ID、出行天数、预算、主题偏好、出发城市、成团人数、特殊要求、状态。
• 订单表（order）：订单号（唯一业务编号）、用户ID、团体ID（可空）、路线ID、订单金额、支付状态、订单状态、创建时间、支付时间。
• 旅行团表（travel_group）：团长ID、团名称、成团人数上限、当前人数、出发日期、状态、备注。
• 成员表（group_member）：团体ID、用户ID、成员角色、参与状态、缴费金额、缴费时间、退出时间。
• 评价表（review）：订单ID、用户ID、评分、内容、出行后审核标记。
• 报价变更表（quote_change_log）：订单ID、旧金额、新金额、变更原因、操作人ID、变更时间。
• 公告表（notice）：标题、内容、类型、发布状态、发布时间。

这套设计的核心思想是：路线与订单分离、订单与团体松耦合关联。路线是静态资源，可以被多个订单引用；订单记录的是交易行为；团体是人与组织的关系载体，与订单通过团体ID关联但不在订单表里冗余太多团体细节。

4.2 容易被忽视的索引优化

数据量小的时候索引可有可无，但答辩老师一定会问"这个表字段建索引了吗？你的查询会不会全表扫描"。我在实践中加了这些索引，逻辑也说得通：

• 订单表的（user_id, status）联合索引：支撑"我的订单"页面按用户和状态筛选。
• 订单表的（group_id, status）：支撑"某团体的订单查询"。
• 路线表的（status, theme）：支撑首页按主题筛选上架路线。
• 需求表的（status）：支撑后台需求池的待匹配查询。

另外要注意电话号码字段如果用varchar存，建议单独建普通索引。手机上号频繁用于登录查询，每次全表扫描在演示环境不觉得慢，但如果老师现场导入了上万条模拟数据，查询响应延迟会非常明显。

4.3 一对多关系下的批量查询优化

一个常见的性能问题是：查询订单列表时，需要同时显示每个订单关联的路线名称和用户昵称。很多人的写法是查完订单列表后，循环再查路线和用户，这样一次页面请求轻松发出几十条SQL，这在答辩现场如果数据量一大就会卡顿。

我用MyBatis的collection标签做了一次性关联查询：

<resultMap id="OrderWithDetailMap" type="OrderVo"> <id property="id" column="order_id"/> <result property="orderNo" column="order_no"/> <collection property="items" ofType="OrderItemVo"> <id property="itemId" column="item_id"/> <result property="routeName" column="route_name"/> <result property="price" column="price"/> </collection> </resultMap> <select id="selectOrderWithDetail" resultMap="OrderWithDetailMap"> SELECT o.id AS order_id, o.order_no, oi.id AS item_id, r.route_name, oi.price FROM `order` o LEFT JOIN order_item oi ON o.id = oi.order_id LEFT JOIN route r ON oi.route_id = r.id WHERE o.user_id = #{userId} ORDER BY o.create_time DESC </select>

这条SQL执行完，内存里就能拼出完整的订单-明细树结构，避免N+1查询问题。注意order是MySQL保留关键字，建表时要加上反引号，否则SQL直接报错，这是我实际踩过的坑。

5. 权限控制与安全细节：答辩时的高频问点

5.1 登录态管理与自定义拦截器

毕设级别的系统不需要做到Spring Security级别，但基本的登录态校验、角色权限隔离、接口防绕过是必须的。我用了Session加自定义拦截器的方式，思路是：

• 登录成功后把user对象放进Session。
• 定义一个权限拦截器，注入Spring容器，注册到WebMvcConfigurer的addInterceptors方法中。
• 配置URL规则拦截什么路径放过什么路径。例如/admin/**必须管理员角色，/user/**必须登录用户，/route/list和首页浏览可以放行。

这里有个重要的坑：静态资源要放行，否则页面样式全挂。我见过不止一个人把拦截器配成/*全拦，结果JS和CSS都被拦截了，页面打开是裸HTML，排查半天才发现是拦截器把静态资源拦了。建议放行规则写成：

registry.addInterceptor(authInterceptor) .addPathPatterns("/**") .excludePathPatterns( "/", "/route/list", "/route/detail/**", "/user/login", "/user/register", "/css/**", "/js/**", "/images/**", "/error" );

自定义注解加拦截器校验权限的做法——定义一个@RequireRole注解，标注在Controller方法上，拦截器里读取注解并校验当前用户角色。思路不复杂，但答辩时你可以说"我通过注解实现了声明式权限控制"，这比"我每个方法开头都判断一下角色"要有说服力得多。

5.2 密码处理与敏感信息防护

密码存储用了BCrypt加密，Spring Security的crypto包里有现成的BCryptPasswordEncoder，不需要把整个Spring Security引进来。注册时加密存储，登录时用matches方法校验。这里要提醒：Session里只放用户ID、昵称、头像这些必要信息，绝对不要把密码放进Session，即使加密过也别放。

另一个安全细节是手机号脱敏。展示用户信息列表时，对手机号中间四位打码（138****1234），需要在VO层做处理而不是改数据库数据。我专门写了一个工具方法处理这个，既满足了页面展示需求，又不破坏原始数据。

文件上传这个环节也要注意安全。头像上传和路线图片上传都涉及文件类型校验，千万不要只信任前端传来的后缀名。我用Content-Type加文件头校验双重检查，并限制文件大小，上传目录放到了项目外部路径，而不是项目classpath里。这样一个是防止上传路径被覆盖，另一个是把上传文件与运行代码物理隔离，部署时也更灵活。

6. 订单支付与退款逻辑：没有真支付环境怎么办

毕业设计要展示一个完整电商闭环，支付环节绕不开，但你又不能在答辩现场真的用商用支付。我的处理方案是：模拟支付通道。

6.1 模拟支付的三种可行方案

第一个方案是直接用数据库事务模拟——点击"立即支付"时，前端弹窗展示模拟收银台，确认后前端请求后端接口，后端开启事务，执行"余额扣减+订单状态变更+资金流水记录"，然后提交事务。这个方案代码量少，事务一致性校验也能展示出来。

第二个方案是接入PayPal沙箱或者支付宝沙箱环境。沙箱环境是真实支付网关的测试环境，可以展示完整的跳转、回调和验签流程。如果导师更看重商业完整性，这个方案更硬核。但缺点是配置流程复杂，而且沙箱环境有时不稳定，答辩现场如果网络出问题就尴尬了。

第三个方案是混合方案——系统里做一个支付渠道标识字段，正常走模拟支付，预留真实支付接口扩展位。我最终选了这个方案，既展示了接口设计的可扩展性，又不会在演示时翻车。

6.2 退款逻辑与资金流水

退款逻辑里最容易漏掉的是"部分退款"。团体订单里如果两个人退出，服务商同意退款，那么退款金额不是订单总额，而是这两个人各自已缴纳的金额。因此资金流水表（fund_flow）必须记录退款是针对order的哪个明细、退给了哪个用户、金额多少、剩余待退金额是多少。

我的实现要点：订单资金操作全部通过一个资金服务类处理，每个操作同步生成一条fund_flow流水。这样可以保证，无论什么时候对账，流水表里的资金进出总和等于订单金额差，不会出现"钱对不上账"的问题。这笔账如果不对齐，答辩现场老师问一句"退款后总金额怎么验证"你就容易卡壳。

7. 从Demo到可演示系统：部署与效果优化的实战经验

代码写完只是第一步，能让它在别人电脑上稳定跑起来，才是关键。

7.1 打包部署的踩坑记录

Spring Boot的打包默认是jar包，内置Tomcat。但我在打包时遇到过三个问题：

第一个是打包后静态资源404。原因是Thymeleaf模板打包进了BOOT-INF/classes目录，而静态资源的路径匹配规则打在classpath下没问题，但如果用了src/main/webapp目录下的资源，打jar包时不会自动带进去。正确做法是把静态资源放在src/main/resources/static下。

第二个是application.properties里的连接串问题。本地跑的时候数据库地址是localhost，到了演示环境可能数据库在另一台机器，密码也不同。我的做法是使用profile配置，分别维护application-dev.properties和application-prod.properties，启动时用--spring.profiles.active=prod指定环境，避免现场改配置文件。

第三个是端口占用。我遇到过打包后启动直接报端口被占用，最后发现是本地跑了两个实例。用server.port=8081换端口解决，同时顺手配置了server.servlet.context-path=/travel给项目加了统一前缀，这样后续部署到nginx做反向代理也更规范。

7.2 演示数据的准备策略

答辩时系统里空荡荡的大列表非常减分。我提前准备了两套演示数据：一套是路线数据，每个主题类别放3到5条路线，配上合适的图片，图片记得用本地文件，不要依赖外部图床，现场没网就全挂了；另一套是订单数据，构造出"已付款、定制中、已完成、已取消"状态齐全的列表，方便现场演示不同状态下的操作流程。

这里有个经验：演示数据的时间区间要合理，比如当前日期是6月，订单的出行日期安排在6月底到7月初才算自然，如果出行日期显示在去年，老师一眼就看出是假数据。而且最好准备一个模拟团体：团长账号登录后能看到团里的成员名单，有人已缴费有人未缴费，这样展示催缴功能时有真实感，比现场新创建一个空白团体更有说服力。

7.3 列表分页与查询性能

管理端的订单列表、路线列表都做了分页，用的MyBatis-Plus的分页插件。分页这件事看似简单，但有个隐藏细节：前端传页码时，页码从1开始，而后台分页插件内部计算offset是page-1，如果前后端约定的边界不一致，会出现第一页数据空白的情况。我在自定义分页对象里统一处理了这个偏移逻辑，并且前端页面确认从1开始传参。

首页的路线筛选用了多条件动态SQL，MyBatis的<if>标签在where条件后拼接，注意每个条件都要带上"and"前缀且第一个条件不能有多余and。这里有个规范写法：where标签配合<trim prefix="WHERE" prefixOverrides="AND|OR">可以自动处理多余and问题，避免SQL语法错误。

8. 关于这个项目我想最后补充的几个认知

做完整个项目，我最想分享的其实不是某个技术点，而是几个底层认知。第一个认知是：毕业设计项目的评分下限由功能完整性决定，上限由你对业务逻辑的解释能力决定。功能齐全、页面能跑、流程顺畅，这是"能过"的基础；但如果你想拿优秀，必须能在答辩时把一个业务决策的前因后果讲清楚——为什么订单状态要设计成这几个而不是两个？为什么团体和个人要分表？为什么要设计报价变更记录表？这些问题的答案，就是你这篇论文或项目的灵魂。

第二个认知是：做项目时"想清楚再动手"比"边做边想"省的时间多得多。我前期在表结构设计上花了大约一半的开发时间，后面真正写代码反而很快，因为字段关系理清了，ServiceImpl里的每个方法基本就是按业务流程一条龙写下来。如果你发现自己写着写着频繁回去改表加字段，停下来想一想，很可能是前面业务建模就没立住。

第三个认知是从一次演示中得来的。当时我给老师演示团体费用分摊功能，恰好把一个缴费状态演示得很清楚，老师顺着问了句"如果一个人支付成功但系统突然断电，你怎么保证不会重复扣款"。这个问题提醒我，支付相关的核心操作必须用事务加幂等键保护。我在模拟支付的接收接口里做了一个请求幂等键的表单字段，后端根据订单号加操作类型生成唯一幂等记录，重复提交直接拒绝。这种细节平时不起眼，但它是整个系统"可信度"的支撑。

最后一个建议是：不要只把项目当成作业，把每个模块的设计决策记录下来，哪怕只是简单的文档。这会帮你在答辩时快速回忆起当初为什么这么做，也会让整个项目显得有思考、有沉淀。我当初把开发日志写在项目根目录的README里，包括每个阶段的改动原因，最后写设计文档的时候发现，最值钱的素材早就在那里等着了。