呗老心眼极小每年毕业设计季，后台总有一批人拿着同一个题目来问：基于SSM的旅客行李管理系统。这个题看起来像是最普通的信息管理系统，但真做起来，很多人会卡在同一个地方——不是代码写不出来，而是不知道业务该怎么做、状态怎么流转、表怎么设计。我过去几年帮不少学弟学妹审过类似项目，也完整带过两个毕设小组做过行李管理方向的系统，对这套SSM框架教程级别的开发流程还算熟。今天干脆把这套从选题分析到答辩准备的完整过程写出来，尽量少讲空话，多讲能直接用的东西。
下面这些内容，适合已经拿到这个题目的毕业生，也适合想用SSM做一套带“状态跟踪”性质的管理系统、但还没有完整设计思路的同学。行李管理系统本质上是一条典型的“单证流+状态流”业务，搞清楚它的数据模型和状态变更逻辑，再回头看Spring、SpringMVC、MyBatis三者的分工，你会觉得这套经典框架用在这里其实非常顺。
1. 拿到题目之后，先别急着建工程，把业务定义清楚
1.1 为什么同样是增删改查，这个题更容易被问倒
很多毕设管理系统，比如班级管理、图书管理，核心就是一张主表加几张关联表，业务上基本是线性操作：新增一条、查一个列表、改一下详情、删一条记录。做完这些，再凑个登录、导出Excel，一个系统就成型了。但“旅客行李管理”不一样，它蹭着航空物流的边，天然带着一个“状态变化”的问题。
如果你不管状态，把行李表做成只有“登记了”和“被领取了”两个状态，答辩老师随便问一句“一件行李从值机托运到最终提取，中间经历了哪些环节？你的系统怎么记录这个过程？”你会发现自己很难回答。因为业务上，行李在值机柜台称重、贴牌、过安检、分拣、装机、卸机、上转盘、被旅客提取，每个环节都是一个节点，每个节点都可能发生异常，比如安检不合格退回、错运到别的航班、到达后没人领取。
所以做这个题目，第一步不是打开IDEA建Spring项目，而是把业务边界想清楚。你是做机场行李全流程追踪，还是做简化版的“柜台寄存/提取管理系统”？如果是后者，那状态字段可以简单一些，桌面模式是“寄存中→已提取”；但如果你连标题都说旅客行李管理，通常老师默认你至少能覆盖托运到提取的流程。我建议在论文和系统里采用“值机托运—分拣—装机—到达—提取”这条主线，再补一个异常状态，这样既不算过度设计，又足够支撑起一篇毕设论文的业务分析章节。
1.2 SSM三件套在这个项目里的真实分工
很多同学能搭出SSM框架，但对三者的边界只停留在“Spring管对象、SpringMVC管请求、MyBatis管数据库”这句话上。到了这个项目里，你要能举出具体例子。
Spring最核心的贡献是IoC容器和AOP事务。行李登记时要同时写行李主表和行李状态轨迹表，如果第二张表插入失败，第一张表也得回滚，这个能力来自Spring的声明式事务，靠@Transactional完成，而这背后的核心是AOP动态代理。SpringMVC负责把浏览器的URL路由到Controller方法，比如/baggage/checkIn、/baggage/trace/list，同时负责参数绑定和JSON返回。MyBatis则负责把Java对象和数据库表映射起来，尤其适合这种SQL条件多变的管理系统，动态SQL写起来非常直观。
理解到这个层面之后，你在论文的“关键技术介绍”部分就不会只是抄书上那段框架概念了，而是能写清楚“本系统如何使用Spring管理Service对象、如何通过SpringMVC接收行李查询请求、如何利用MyBatis动态SQL完成多条件检索”，这一步就能拉开和普通模板化论文的差距。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 画一张业务地图：行李在系统里到底走哪些节点
2.1 一个最简单的全流程闭环怎么设计
做业务设计时，我喜欢先把“状态/动作/角色”三个要素列出来。这个系统里，行李对象至少要有五六个状态，每个状态要对应一个操作动作和操作人。
我建议这样设置状态编码，方便数据库存储和前端展示：
| 状态编码 | 状态名称 | 触发动作 | 典型角色 |
|---|---|---|---|
| 0 | 已收运 | 值机柜台托运行李，生成行李牌 | 值机员 |
| 1 | 安检中 | 行李进入安检通道 | 安检员 |
| 2 | 已分拣 | 安检通过，按航班分拣 | 分拣员 |
| 3 | 已装机 | 行李装上飞机货舱 | 装载员 |
| 4 | 已到达 | 航班到达，行李进入提取转盘 | 到达管理员 |
| 5 | 已提取 | 旅客凭凭证完成核验提取 | 行李查询员 |
| 6 | 异常 | 安检退回/错运/破损/无人认领 | 系统标记 |
如果你觉得六七个状态对毕设来说偏多，可以砍到四个核心状态：0-已收运、1-运输中、2-已到达、3-已提取，加上一个99-异常。砍掉状态没问题，但要在需求分析里能自圆其说。我最怕的是学生系统里有两个状态，一个是“未领取”，一个是“已领取”，论文里却写“本系统实现了行李全流程追踪”，这是明显的逻辑漏洞，答辩老师一眼就能看出来。
2.2 角色权限和功能模块不要贪多
旅客行李管理系统不需要像真正的机场系统那样对接离港系统、安检系统，也不需要做自助行李托运设备。毕设的功能模块控制在六个左右就够了：系统登录与用户管理、旅客信息管理、行李登记管理、行李状态跟踪、行李查询统计、基础数据管理（航班和柜台信息）。
用户角色建议拆成三类：系统管理员、值机员、行李查询员。管理员维护用户、航班等基础数据；值机员负责登记行李、办理状态流转；行李查询员则负责查询、处理异常、办理提取。这里可以顺势用上SpringMVC的拦截器做权限控制，按角色名判断是否放行请求，既实现了功能，又能在论文里写“系统采用拦截器实现访问控制”，比只做一个登录功能要有说服力得多。
2.3 异常分支是体现系统完整度的地方
每个系统都做得通主流程，真正体现水平的是异常分支。行李管理里常见的异常场景有三个：
第一个是安检未通过，行李需要从“安检中”退回到值机柜台，这时候不是简单把状态改成0，而是要在状态追踪表里追加一条“安检退回，原因：疑似超规物品”的记录。第二个是错运，行李被装上别的航班，系统需要有一条“改签航班”的记录，关联到新的航班号。第三个是无人认领，到达后超过一定时间未提取，系统自动或人工把状态置为“异常”，并记录滞留天数。
这些异常分支不需要写得多复杂，但要在数据库表里留出remark、operator_id、operation_time这些字段，并在代码里设计好状态变更的接口。当你做到这一步，你的