我帮人带过不少SpringBoot的管理系统项目，说实话，图书管理、学生信息、班级管理这类题目已经被做烂了，答辩时老师一听标题就没多大兴趣。但"行李寄存管理系统"这个选题，第一次看到时我就觉得有点意思——它业务链路清晰、实体关系不复杂、又带一点硬件联动的想象空间（扫码、柜门开关、超期计费），无论做课程设计还是毕设，都很容易讲出东西。
这篇就把我在做这个"基于SpringBoot的行李寄存管理系统"时的完整思路写出来，涵盖业务梳理、数据库设计、核心功能实现、部署步骤，以及我实际踩过的坑。如果你手上正好也有一份类似的源码加部署文档，不知道怎么讲、怎么改、怎么演示，这篇可以帮你把整个项目吃透。
1. 为什么选"行李寄存"这个题目：业务形态与选型逻辑
1.1 行李寄存背后的真实业务链路
很多人一听"行李寄存"就以为是个小功能，其实它的业务闭环相当完整，这也是我推荐这个选题的核心原因。你在高铁站、景区、商场里看到的自助行李寄存柜，背后至少包含这几个环节：
- 用户在终端前选柜型（小柜、中柜、大柜，对应不同收费标准并依据行李箱尺寸匹配）；
- 系统分配一个空闲柜子，生成取件凭证（可以是取件码、二维码或小票条码）；
- 柜门打开，用户放入行李；
- 用户离开，计时开始；
- 用户回来，扫凭证，系统算出寄存时长和费用；
- 支付完成，柜门打开，用户取走行李，柜子重新变成空闲。
把这个链路翻译成软件系统的功能，就是柜子管理、订单管理、计费规则、凭证管理、超期处理、数据统计。它有明确的实体关系、有状态流转、有并发场景（比如同时多人存包），还涉及到钱的计算，非常适合作为SpringBoot的项目题——既能展示CRUD基本功，又能体现你在业务设计上的思考。
1.2 技术栈怎么定：SpringBoot为主，前端左右横跳
技术选型是这个项目第一个要讲清楚的点。核心后端用SpringBoot这个没悬念，问题在于前端和配套组件怎么搭配。我见过几份同一题目的不同实现，常见的组合有四种：
| 方案 | 技术栈 | 适用场景 | 说明 |
|---|---|---|---|
| A | SpringBoot + Thymeleaf + Bootstrap | 课程设计、快速演示 | 服务端渲染，结构简单，部署方便 |
| B | SpringBoot后端 + Vue3 + Element Plus | 毕设、前后端分离 | 前后端分离更规范，适合展示工程化能力 |
| C | SpringBoot后端 + 微信小程序 | 偏商用场景 | 用户扫码存包更贴近真实产品，但有微信认证要求 |
| D | SpringBoot + JSP | 传统课设 | 兼容旧环境，但实际已很少用 |
我自己做这版项目时用的是方案B——后端SpringBoot，前端Vue3加Element Plus。理由很简单：前后端分离是目前的主流结构，答辩时讲API设计、讲跨域、讲Token登录，都比"页面直接调Controller"更有话可说。如果你只是想快速交作业，方案A也可以，部署时少跑一个前端工程，省去不少繁琐的配置。
配套组件里，数据库我用MySQL，ORM用MyBatis Plus，权限方面用JWT做登录令牌，项目简单没上Redis，但如果你想让演示效果更亮眼，可以加一个Redis做凭证码的过期缓存——这个后面说。
1.3 角色权限划分必须有，这是评分关注点
行李寄存系统一般分三个角色，很多参考项目只做管理员和用户两级，我建议至少做三级，因为"操作员"这个角色最贴近线下场景。
- 管理员：管理柜子信息、管理计费规则、查看全部订单、统计营收；
- 操作员：针对人工寄存点，可以代客下单、代客取件、处理超期订单；
- 用户：自助存包、取包、查看自己的寄存记录和费用明细。
三级权限在数据库层面就是给用户表加一个role字段，后端通过拦截器或Spring Security判断接口权限。这个点讲出来老师会认为你确实考虑了实际运营场景，而不只是抄了个多模块增删改查。
2. 数据库设计：把"存包取包"翻译成表结构
2.1 六张核心表的字段设计
数据库设计直接决定后面的代码怎么写。我最终落地的表结构大概是这样的：
柜子表（locker）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| locker_no | varchar | 柜子编号，如A-01 |
| type | tinyint | 柜型：1小柜、2中柜、3大柜 |
| location | varchar | 位置描述，如"A区第3排" |
| status | tinyint | 0空闲 1占用 2维修 3超期锁定 |
| current_order_id | bigint | 当前占用订单ID，空闲时为空 |
用户表（user）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| phone | varchar | 手机号，注册/登录账号 |
| password | varchar | BCrypt加密后的密码 |
| nickname | varchar | 昵称 |
| role | tinyint | 1管理员 2操作员 3用户 |
| create_time | datetime | 注册时间 |
订单表（orders，避开order关键字）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| order_no | varchar | 订单编号，规则如日期+随机数 |
| locker_id | bigint | 柜子ID |
| user_id | bigint | 用户ID，可为空（线下操作） |
| checkin_time | datetime | 存包时间 |
| checkout_time | datetime | 取包时间，空表示未取 |
| expect_fee | decimal | 预计费用（存包时按规则试算） |
| actual_fee | decimal | 实际费用，取包时最终计算 |
| status | tinyint | 0寄存中 1已完成 2超期 3已清理 |
| voucher_code | varchar | 取件凭证码 |
计费规则表（pricing_rule）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| locker_type | tinyint | 对应柜型 |
| first_hour_fee | decimal | 首小时费用 |
| extra_hour_fee | decimal | 超出首小时后每小时费用 |
| daily_cap | decimal | 每日封顶价 |
| overdue_daily_fee | decimal | 超期后每日费用 |
操作日志表（operation_log）
这个表容易被忽略，但实际很有用：谁在什么时间对哪个柜子做了什么操作（管理员改价格、操作员强制开柜），都记录下来。答辩时这一张表就能说明你考虑了系统审计需求。
遗失/异常记录表（abnormal_record）
记录旅客离场时的异常情况，如凭证丢失、物品遗漏、柜门故障等，方便回溯。
2.2 订单状态机与计费规则
订单状态是整个系统最核心的状态机，我建议用一张图讲清楚，代码里维护好这个状态流转：
- 存包成功时，订单生成，status=0（寄存中），柜子status=1；
- 用户扫码取包、费用结清，订单status=1（已完成），柜子status=0；
- 超过设定寄存时限（比如48小时），系统定时任务扫描，订单status=2（超期），柜子status=3（超期锁定），用户无法自助取包，需要找操作员处理；
- 操作员人工处理补费后，订单status=1，柜子释放；如果长期无人处理，管理员标记清理，订单status=3，柜子恢复空闲。
这个状态映射到代码里就是一张枚举表。我最开始写时也偷懒直接用int散落在业务逻辑里，后来发现前端展示要翻译、统计要筛选、定时任务要判断，三种地方各写一遍就很容易出错。统一收敛成一个OrderStatusEnum，所有判断走枚举，你会少踩很多坑。
计费规则这里我多说一嘴：不要写死在代码里。把计价逻辑抽出来，做成一张可配置的规则表，这是"未来验证"设计。你的项目展示时可以说"调整计费不重启系统"——这句话在答辩里比"我写了增删改查"值钱得多。计算方式我给的是：不满1小时按1小时计；超过首小时部分按extra_hour_fee每小时累加；当日封顶价用于防止长时间寄存费用过高；超期后按overdue_daily_fee每天累加。
2.3 为什么箱柜编号不能当主键
这是我帮别人改代码时发现的一个典型问题。很多人设计表时觉得"柜子编号是唯一的，那直接用locker_no做主键不就行了"。短期看确实能跑，但一旦你把编号从A-01改成B-01，或者同一个柜子在不同时间段被不同订单占用，业务上就无法区分历史记录。
正确做法是：主键用自增id，locker_no只是业务编号，给它加一个唯一索引保证不重复即可。所有订单表通过locker_id关联到柜子的id。同理，订单表的order_no也是业务编号，主键用id。这属于数据库设计的基本素养，但现实中我见过太多把业务编号当主键的项目了，值得展开讲一下。
3. 核心功能实现：从存包到取包的完整链路
3.1 存包流程：选柜、分配、生成凭证
存包这个接口是整个系统业务起点，也是最容易被写坏的地方。最普通的写法是"查到空闲柜子→插入订单→更新柜子状态"，三步分开。但如果你做成三步独立执行，在高并发下会出现两个用户抢同一个柜子的问题。
建议的做法是把"分配柜子"做成一个原子操作，核心SQL长这样：
UPDATE locker SET status = 1, current_order_id = ? WHERE id = ? AND status = 0在MyBatis Plus里，用UpdateWrapper执行update，判断返回的受影响行数。如果受影响行数为1，说明这个柜子是空闲的且被你抢到了；如果返回0，说明别人已经先一步占用了，就换一个柜子继续试。
真正的存包流程我拆成五步：
- 用户选择柜型，前端请求创建寄存订单接口；
- 后端根据柜型查询空闲柜子列表，按"柜子编号升序"选第一个；
- 执行上面的原子更新，抢占柜子；
- 抢占成功后插入订单记录，状态为"寄存中"，生成取件凭证码；
- 返回给前端：柜子编号、凭证码、存包时间、预计费用。
凭证码生成这里有个细节。很多学习项目直接UUID，一大串字符串用户根本没法手输。我实际用的是6位数字加字母组合，从固定字符集里随机抽取，同时查重保证唯一。这就够用了，自助取件机上用户扫码或者手输都方便。
3.2 取包流程：识别凭证、算钱、释放柜子
取包的核心是"凭证校验+费用计算+状态释放"。你先根据凭证码查到订单，要校验三点：订单存在、订单属于当前用户（或者操作员代办）、订单状态不是"已完成"。
校验通过后，按规则表算费用。这里要做一次时间差计算：
long hours = Duration.between(checkinTime, LocalDateTime.now()).toHours(); if (hours < 1) { hours = 1; } BigDecimal fee = firstHourFee; if (hours > 1) { fee = fee.add(extraHourFee.multiply(BigDecimal.valueOf(hours - 1))); } if (fee.compareTo(dailyCap) > 0) { fee = dailyCap; }算完费用要区分"线上支付"和"线下确认"两种模式。自助场景通常接一个模拟支付（直接点"确认支付"就行，毕设没必要真的去接微信/支付宝），支付成功调用取包接口；人工场景则是操作员直接确认收款并完成取包。
取包接口后端要同时完成四件事：把订单状态改成"已完成"、写入取包时间、把柜子状态改成"空闲"、清空柜子的current_order_id。两个更新建议放在一个事务里，避免出现"订单已取走但柜子还是占用"的数据不一致。
3.3 超期订单处理：定时扫描与人工兜底
超期处理是这个系统区别于普通仓库管理的关键功能。实现思路是SpringBoot自带的任务调度，在启动类或者配置类上用@EnableScheduling开启，然后写一个定时任务类：
@Component public class OverdueCheckTask { @Autowired private OrdersMapper ordersMapper; @Scheduled(cron = "0 0 */2 * * ?") public void processOverdueOrders() { // 查询所有寄存中且存包时间超过48小时的订单 // 逐个执行：订单置为超期状态、柜子置为超期锁定 } }需要注意，定时任务只负责"标记状态"，不要直接释放柜子。释放必须留给人工处理，因为行李还在柜子里，你不可能远程把它扔出去。超过一定天数（比如7天）无人处理，管理员在后台做"清理登记"，此时柜子才真正释放——对应前面状态机里的"已清理"状态。
3.4 数据看板怎么做
数据看板是我的加分项，虽然标题没要求，但做出来演示效果很好。管理员首页展示几张图：今日存包量、今日取包量、当前占用柜数、今日营收、近7天寄存趋势。实现方式很简单，后端写几个统计SQL，前端用ECharts画柱状图和折线图。
-- 今日存包量 SELECT COUNT(*) FROM orders WHERE DATE(checkin_time) = CURDATE(); -- 当前占用柜数 SELECT COUNT(*) FROM locker WHERE status = 1 OR status = 3; -- 近7天寄存趋势 SELECT DATE(checkin_time) AS d, COUNT(*) AS cnt FROM orders WHERE checkin_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(checkin_time);你别小看这几个统计SQL，不少候选人在答辩现场就是把它们讲成"系统具备经营分析能力"。当然，如果你的这个项目原本没有看板，也可以在OrdersServiceImpl之类的地方补几个统计方法，成本极低，收益非常明显。
4. 从源码到跑通：部署流程与常见错误排查
4.1 本地环境准备清单
拿到一个SpringBoot行李寄存管理系统的源码包之后，很多第一次做部署的同学会卡在"怎么把项目跑起来"这一步。我这里给一个最小化环境准备清单：
- JDK 1.8或11（大部分毕设项目用1.8，用17+的话要注意pom里的依赖是否兼容）；
- Maven 3.6以上（如果源码里带mvnw，也可以用wrapper）；
- MySQL 5.7或8.0，本地启动并创建数据库；
- 可选：Redis（这个项目没用到，但如果你要扩展凭证码缓存就需要）；
- IDE建议直接用IDEA，社区版就能跑SpringBoot项目。
其中最容易出问题的就是JDK版本和Maven版本。我遇到过一次，项目用的SpringBoot 2.3.7（对应Java 8），结果本机默认JDK 17，一启动直接报"Unsupported class file major version"。所以第一步一定先检查java -version和pom.xml里声明的版本是否一致。
4.2 配置文件一定要改的三处
打开src/main/resources里的application.yml（或application.properties），至少有这三个位置需要改：
数据库连接
spring: datasource: url: jdbc:mysql://localhost:3306/luggage_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码如果你用的是MySQL 8.x，别忘了把驱动改成com.mysql.cj.jdbc.Driver，5.x使用com.mysql.jdbc.Driver。更稳妥的做法是直接在pom里统一用mysql-connector-java的8.0.x版本，连接串加上serverTimezone，否则启动时会报时区错误。
端口
server: port: 8080如果8080被占用，改成8090或别的。启动时看到"Port 8080 was already in use"，要么换端口，要么把占用进程杀掉。Windows下排查：netstat -ano | findstr 8080，然后taskkill /F /PID 进程号。
文件上传路径（如果有）
如果项目里有用户上传头像、上传遗失物品图片的功能，通常会有类似upload.path: D:/upload/的配置项。改成你自己机器上存在的目录，不然后台上传图片时会出现"系统找不到指定路径"。这是非常隐蔽的坑，复制项目到新电脑最容易漏掉这一项。
4.3 数据库初始化顺序
拿到源码时，数据库文件一般在项目目录下，常见的有sql/luggage.sql、db/init.sql或者直接就是document/database.sql。我的建议是，不要在IDEA的数据库工具里一上来就跑整个脚本，那样出错不好定位。
正确顺序是：
- 先手动创建数据库：
CREATE DATABASE luggage_db DEFAULT CHARACTER SET utf8mb4; - 打开SQL文件，确认它没有
CREATE DATABASE和USE语句，如果有，把这两行删掉； - 在新建的luggage_db库下执行整个脚本；
- 执行完检查核心表数量（locker、user、orders、pricing_rule等），用
SELECT COUNT(*) FROM locker;验证柜子表有没有初始数据。
我踩过一次坑：SQL脚本里表名用了order这种MySQL保留字，执行时报语法错误。正常的项目会写成orders，但有些同学自己建的库可能没注意。处理方式是在表名两边加反引号：
CREATE TABLE `order` (...)不过强烈建议你直接把表名改成orders，反引号治标不治本。
4.4 打包运行与常见报错
部署文档里最常写的两种方式，一是IDEA里直接点启动，二是打包成jar运行。毕业设计答辩前建议都试一遍。
Maven打包命令：
mvn clean package -DskipTests如果打包成功，target目录下会生成一个luggage-0.0.1-SNAPSHOT.jar，然后执行：
java -jar luggage-0.0.1-SNAPSHOT.jar前面配置没问题的话，看到Started LuggageApplication in x.xxx seconds就算启动成功。
这里列出我实际遇到频率最高的几个报错：
| 报错信息 | 原因 | 解决办法 |
|---|---|---|
| Access denied for user 'root'@'localhost' | 数据库密码不对 | application.yml里密码改成正确的 |
| Unknown database 'luggage_db' | 没有创建数据库或库名不一致 | 先执行CREATE DATABASE |
| Table 'xxx.locker' doesn't exist | 没执行SQL脚本/表名不对 | 重新导入SQL脚本，核对库名 |
| Cannot load driver class: com.mysql.cj.jdbc.Driver | 驱动版本或依赖缺失 | 确认pom里有mysql-connector-java及版本 |
| Failed to configure a DataSource | 启动时没读到数据源配置 | 检查yml缩进、配置文件位置 |
| 前端页面白屏/404 | 前端没打包或静态资源路径不对 | 重新构建前端，dist放到src/main/resources/static下 |
前端工程是Vue的话，部署流程是：前端项目根目录执行npm install→npm run build，然后把dist目录里的内容复制到SpringBoot的src/main/resources/static/下，重新打包后端。这样SpringBoot就能直接托管前端页面，访问http://localhost:8080就是系统首页，非常方便演示。
5. 实际使用中发现的问题与优化建议
5.1 并发取同一柜子：一个容易被忽略的bug
有次我测试时开两个浏览器窗口，模拟两个用户同时对一个空柜子发起存包请求。用最原始的"查到第一个空闲柜子→存订单→更新柜子状态"三步逻辑，结果两个请求都拿到了同一个柜子编号，订单都成功了，柜子状态也被覆盖。
这个问题的根源就是前面3.1里说的"分配柜子"没有做成原子操作。修复方案我已经在前面写过了：用UPDATE locker SET status=1 WHERE id=? AND status=0判断影响行数。但还有一个细节——如果项目里所有柜子都被占了，系统要给用户一个友好的提示，而不是报500错误。所以分配柜子之前先查一次总数，如果没有空闲柜子就抛出业务异常"暂无可用的行李柜"。
事务控制也重要：抢占柜子、生成订单这两个动作要在同一个事务里。因为如果生成订单失败但柜子状态已经改成占用，柜子就"凭空消失"了。用@Transactional把Service方法包起来即可。
5.2 凭证丢了怎么办：人工兜底流程
现实世界里用户丢凭证太常见了。我看过不少项目直接写死"凭证丢失无法取包"，这在答辩时很容易被老师一句话问住。建议在操作员端加一个"人工取包"入口：
- 用户报手机号或身份证号，操作员按手机号查未完成的订单；
- 操作员确认物品特征与订单登记信息一致；
- 操作员点击"强制开柜取包"，系统记录一条操作日志；
- 订单按实际时长计算费用、缴纳后完成。
这个流程不复杂，但体现的是需求分析时是否考虑"异常情况"的意识。对毕设来说，这就属于加分项。另外可以在存包时让用户登记手机号，没带手机也能靠手机号查单，比纯凭证码模式更贴近真实场景。
5.3 凭证码过期和安全的处理
凭证码默认30天有效（部分项目没有这个需求），但如果自助寄存时间过长，凭证码会泄漏或者被别人看到。我建议给凭证码加上一层"混淆逻辑"：生成时不要用连续的订单号，而是通过随机码映射。取包时后台根据凭证码找到订单ID，再校验订单状态和当前时间。
同时登录功能记得对密码做加密。如果你拿到的源码里密码是明文存储的，务必改成BCrypt。Spring Security或者SpringBoot自带的BCryptPasswordEncoder都能用。这个不一定要写进文档，但代码review时看到明文密码总是说不过去。同理，JWT的密钥不要硬编码在业务代码里，放到配置文件中，演示时不泄漏即可。
5.4 还可以怎么扩展
如果答辩后你还想继续玩这个项目，或者想在工作简历里写得更漂亮，我有几个具体的扩展方向：
- 接入物理柜硬件：用HC-06蓝牙模块或者ESP8266，通过串口/HTTP指令控制柜门锁，把系统从"模拟开柜"变成"真开柜"；
- 凭证码改用微信小程序扫码：用户存包后展示小程序码，取包时小程序里点击取件，体验更接近商业产品；
- 增加消息通知：取包成功、超期提醒用短信或公众号模板消息推送（用阿里云短信服务即可）；
- 增加大屏模式：在后台做一块统计大屏页面，适合演示时投影出来，视觉冲击力很强。
这些扩展并不改变原有项目的核心结构，只是在边缘加功能，但对项目的"天花板"提升很明显。毕竟同样是行李寄存系统，能做到"物联网联动"和只做"模拟柜门"的复杂度完全不是一个档次。
6. 我的实操建议
在整个项目从源码到跑通再到优化的过程里，我最深的体会是：这个题目虽然不起眼，但它天然适合展示完整的业务闭环。很多管理系统项目做到最后都是在堆CRUD页面，而这个系统因为有"计费计算""状态流转""超时任务""并发抢占"这些真实业务逻辑，代码里能讲的细节非常多。
如果你手上已经有源码和部署文档，我建议按这个顺序推进：先把数据库跑起来，再用接口测试工具把存包、取包两个主流程调通，最后再打开前端页面看效果。不要一上来就急着改代码，先把原项目跑通，你才知道它原本的设计哪里好、哪里别扭。
要改的话优先改三处：第一是把计费规则从写死改成配置表，这个演示时最出效果；第二是给取包流程加上异常处理，比如凭证码错误次数锁定；第三是把后台首页的统计做成图表，视觉冲击力强，老师一眼就能看出工作量。
最后分享一个小技巧：展示时不要只在本地跑，提前把项目打包成jar放到答辩用的电脑上，演示前重新启动一次，确保数据库服务和端口都正常。我见过太多人当场演示时发现数据库没开、端口被占、前端缓存加载错乱，这些低级问题比代码bug更影响印象分。只要主流程稳，项目本身讲清楚，这个题目拿个不错的评价完全没问题。
