Wong Kosheng临近课程设计或毕业设计选题的时候，“剧本杀系统”这类题目经常会让同学犹豫：它到底只是普通增删改查，还是能做出真正有技术含量的项目？一个基于SpringBoot+Uniapp的剧本杀游玩一体化平台微信小程序，会不会被老师当成“页面堆砌”？
我自己的判断是：这类题目选得好不好，关键在于你能不能把一个完整的线下消费场景翻译成线上系统。剧本杀平台不是“问卷系统”那种一页CRUD的东西，它背后有剧本分类、场次管理、拼车余位、预约状态流转、订单评价，甚至并发情况下如何防止同一场次超卖。做完整一轮之后，你会明显感觉自己的后端设计和前端联调能力都被打磨了一遍。
这篇文章不是抄代码的流水账，而是把整个项目的思路完整复盘出来。包括最初怎么拆需求、后端为什么这样搭、数据库的表为什么这么设计、小程序端怎么和接口联调，以及最后交材料、准备答辩时容易忽略的几个坑。只要你正在做或准备做同类课题，按这套思路走一遍，至少能少走半个月弯路。
1. 定制业务地图：从剧本杀线下场景推导平台功能
1.1 先按用户路径把功能翻译成需求列表
很多同学拿到“一体化平台”这种题目，第一反应是去网上看别人的系统有什么菜单，然后照搬。这样写出来的需求文档看起来很全，但做起来非常虚。我更推荐从线下玩剧本杀的路径倒推。
想象一个用户打开这个小程序后发生了什么：
- 进入首页，看到轮播图和热门剧本推荐。
- 进入剧本列表，按题材、人数、难度筛选。
- 点进详情页，看剧本简介、角色配置、时长、价格，同时看到近期可预约的场次。
- 选择场次，填写预约人数和联系方式；如果人数不够，看到当前已有几人“上车”，这就是拼车信息。
- 提交预约后，在“我的预约”里跟踪订单状态，从待确认到已完成。
- 体验结束后，对这次预约对应的剧本和场次写评价。
- 管理员在小程序之外（或后台页面）维护剧本、分类、轮播图、场次信息。
把这串流程翻译成后端模块，就是用户模块、剧本模块、场次模块、预约拼车模块、订单评价模块。这样的模块划分是直接从真实场景里长出来的，而不是靠背。需求文档里画用例图的时候，也只需要围绕这几个模块展开，每个模块三四个用例就够，不要贪多。
1.2 角色权限只拆两套：普通用户和管理员
课设和毕设阶段，我最不建议在角色上做太多层级。有人一上来就设计“玩家、店长、主持人、超级管理员”四个角色，结果权限拦截器写了一半，就把自己绕晕了。
正确做法是先收敛成两类：普通用户和管理员。普通用户登录小程序，完成浏览、预约、评价、收藏这些操作；管理员负责维护剧本和场次，同时对预约记录做管理。如果你担心“店长”和“主持人”体现不出来，可以在管理员上增加一个role_code字段，或者放在菜单权限里做区分，但不要为此建一套独立角色表。这样既能在答辩时说清楚“不同的角色权限边界”，又不会因为过度设计耽误开发进度。
1.3 把“状态机”提前画出来，比编码更重要
我见过太多同学后端接口写完了，才发现预约单没有状态变更，场次满员后依然能被点击。归根结底是没有提前画状态流程。
剧本杀平台的核心状态有两条线：
- 场次状态：可预约 -> 已满员 -> 已开场 -> 已结束
- 预约单状态：待确认（如果有支付环节） -> 已预约 -> 已取消 -> 已完成 -> 已评价
这两条状态线一定要在设计和数据库阶段就写清楚。我在做这个项目的时候，是先在纸上画了一条流程图，标注每个状态允许哪些操作、操作之后跳到哪个状态，然后才去建表。数据库中每个相关表都有status字段，小程序端根据状态渲染按钮：比如状态为“已取消”时，不能点“去评价”；状态为“可预约”但余位不足时，按钮直接置灰。
这个状态机在答辩时非常加分。只要有老师问到“你的订单状态是怎么流转的”，一张图把流程讲清楚，就能压住场子。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型复盘：SpringBoot和Uniapp不能只是“听说好用”
2.1 后端版本“够用就好”：Java 8/11配合SpringBoot 2.7.x
版本选型是这个项目第一个容易踩坑的地方。网上的教程五花八门，但我的建议很明确：课程设计和毕业设计优先用SpringBoot 2.7.x，配合Java 8或Java 11。为什么不用最新的SpringBoot 3.x？因为SpringBoot 3强制要求Java 17以上，而不少教程里常用的MyBatis-Plus旧版本、某些代码生成器、Swagger相关依赖，在新版本环境下会出现兼容性问题。好不容易把项目跑起来了，结果卡在一个莫名其妙的依赖报错上，极其浪费时间。
如果你因为课程要求必须用Java 17或SpringBoot 3.x，也可以，但务必先确认这些依赖都支持新版本：
| 依赖组件 | 推荐方案 | 注意事项 |
|---|---|---|
| SpringBoot | 2.7.x | 最稳定，兼容性最好 |
| JDK | 8 或 11 | 版本过低或过高都可能踩坑 |
| MyBatis-Plus | 3.5.x | 注意适配SpringBoot版本 |
| 接口文档 | knife4j 或 springfox | 老版本在SpringBoot 2.6+容易报路径匹配错误 |
| Lombok | 随IDE版本即可 | 必须确保IDE已经安装插件 |
在实际项目中，我用了SpringBoot 2.7.18、MyBatis-Plus 3.5.3和JDK 8，整套组合几乎没有遇到版本陷阱，这让我把时间都花在业务代码上，而不是排查“为什么注解不生效”。
2.2 MyBatis-Plus让CRUD更轻，也让文档更好写
数据访问层选MyBatis-Plus，不是因为它花哨，而是因为它在最简单的情况下能大大减少重复代码。普通的单表增删改查直接继承BaseMapper<T>，分页用selectPage，条件查询用LambdaQueryWrapper，基本不需要手写XML。在剧本列表这类需要动态拼接条件的场景下，它的价值很明显：
java复制LambdaQueryWrapper<ScriptInfo> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(StringUtils.isNotBlank(categoryId), ScriptInfo::getCategoryId, categoryId)
.like(StringUtils.isNotBlank(name), ScriptInfo::getName, name)
.eq(StringUtils.isNotBlank(tag), ScriptInfo::getTag, tag)
.orderByDesc(ScriptInfo::getCreateTime);
Page<ScriptInfo> page = scriptInfoMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);
这段代码逻辑非常直观，条件为空时不参与过滤，名称用模糊搜索，排序按创建时间倒序。答辩时如果老师问“你的搜索分页怎