ki-pi最近不少同学在后台问我毕业设计到底怎么选，正好我手上刚整理完一套可以拿来即用的 Spring Boot 项目——秘境逃脱管理系统，编号 07388，主语言是 Java（Spring Boot），同时配了微信小程序端，还预留了单片机硬件联动的扩展位。这个项目不光是能直接跑起来的成品，还带完整文档，从开题报告、任务书到答辩 PPT 都能覆盖，特别适合正在愁毕设的计算机、软件工程、物联网、大数据专业本科生。今天我就把这个项目的选题思路、技术方案、数据库设计、核心代码实现到线上部署完整拆一遍，顺便把我在准备过程中踩过的坑、总结的答辩问答也一起整理出来，想少走弯路的同学可以直接抄作业。
秘境逃脱管理系统本质上是一个以密室逃脱、沉浸式剧场、实景解谜门店为业务背景的预约与管理平台。它既包含面向 C 端玩家的微信小程序，也包含面向门店管理员和总后台运营者的 Web 管理端，还预留了硬件设备（单片机控制门锁、传感器）的联动能力。管理端可以做商户入驻管理、密室主题维护、门店排班、预约审核、订单查看、评价管理、公告发布；小程序端则负责让玩家浏览密室主题、查看可预约时段、在线预约下单、取消预约、发布评价、查看历史订单。看到这里你就能理解，它并不是一个简单的 CRUD 系统，而是把预约业务变成了一条完整的交易闭环，这恰好符合高校对毕业设计"业务完整、技术有亮点、工程化规范"的评审要求。
1. 项目概述与选题思路
1.1 秘境逃脱管理系统到底在做什么
先花点时间把业务模型讲透，因为很多时候答辩老师问的第一个问题就是你到底做了一个什么东西。秘境逃脱管理系统从名字上拆解，重点是"秘境逃脱"和"管理"两个关键词。"秘境逃脱"指的是密室逃脱、解谜体验馆这类线下娱乐业态，玩法通常是玩家组队进入一个主题房间，在限时内通过线索寻找、机关破解、团队协作完成逃生任务。这类门店在管理层面会碰到典型的行业痛点：主题场次排期靠手工表格、用户预约只能电话或门店登记、高峰时段经常出现超卖或空场、订单和评价数据散落各处无法沉淀。
"管理"则是系统的核心职责。系统需要服务三类角色：超级管理员（平台运营方）、商家管理员（密室门店老板或店长）、普通玩家（C 端用户）。针对每一类角色，系统都提供对应的功能模块。超级管理员管理商家入驻审核、全局配置、平台数据统计；商家管理员维护门店信息、密室主题、场次库存、核销订单、查看营收；玩家通过小程序完成从发现到体验后评价的完整旅程。这个业务模型放在毕业设计里特别合适，因为它的复杂度不高不低，恰好能展示一个学生完整掌握"用户角色权限 + 核心业务流转 + 前后端联调 + 数据库设计"的全链路能力。
1.2 为什么选这个题目：毕设选题的三个原则
我给很多同学看过毕设选题，说实话，选题选得好不好直接决定后面四个月过得轻不轻松。关于毕设选题，我一直强调三个原则：业务要听得懂、技术要跨层次、数据要能展开。业务要听得懂，意味着你不需要跟答辩老师解释半天这个系统是干嘛的。秘境逃脱、密室预约，属于大众娱乐场景，老师一听就知道你要做什么，不需要额外铺垫。技术要跨层次，指的是系统不能只做纯粹的增删改查，必须要有能拿得出手的亮点，不然答辩时很难拉开差距。这套系统里加了小程序端、Redis 缓存、预约防超卖、单片机硬件联动，每一个都是可以往深处聊的点。数据要能展开，说的是业务场景足够支撑你做出有质感的功能，比如场次库存、订单状态机、用户评价、商家的营收统计报表，这些数据天然有逻辑关系，做出来的系统演示时不会显得单薄。
对比一下网上常见的"学生管理系统""图书管理系统"，你会发现那些项目的功能停留在信息登记层面，根本没有真正的业务流。秘境逃脱管理系统从预约到核销再到评价，业务数据是环环相扣的，答辩时老师顺着你的业务流程提问，你能流畅地讲出每一步的来龙去脉，这种"能讲清楚"的状态比分高价值得多。
1.3 谁适合选这套方案
我最推荐的是一批同学：Java Web 课程学得还不错、Spring Boot 会基本使用、但还没完整独立做过项目的同学。这套系统的难度定位是"进阶实战"，刚好卡在大多数人能跳一跳够得着的位置。如果你是零基础，不建议直接拿这个项目当第一个练手项目，你需要先把 Java 基础、MySQL、Spring Boot 基本使用过一遍再来。如果你已经能独立写接口，这套项目又会帮你补齐小程序开发、Redis 应用、硬件通信这些在课堂上学不到的技能。
物联网、嵌入式方向的同学也可以关注这套项目，因为它在一套完整 Web 系统的基础上，释放了单片机设备接入的扩展接口。你可以把原本独立的单片机课设变成一个大系统里的一个功能模块，这种"软硬结合"的整体方案在毕设评审中相当加分。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术方案选型：为什么是 Spring Boot 全家桶
2.1 语言之争：Java、PHP、Python、C# 到底选哪个
毕业设计社区里常年有人争论用 Java、PHP、Python 还是 C# 写管理系统，我的看法比较直接：如果你想毕业以后走开发岗，优先 Java；如果你想要最短时间做出能跑的系统且基础较弱，Python 或 PHP 可以做备选；如果你所在学校对口的方向是 .NET 技术栈，C# 也不是不行。但综合行情来看，Spring Boot 的生态成熟度、岗位需求量、学习资料的丰富程度，在国内市场几乎没有对手。
这套项目以 Spring Boot 为核心，但我把 PHP、Python、C# 版本也配置了同一套业务模型的实现参考，方便不同编程语言基础的同学做跨语言移植。核心原因是"秘境逃脱管理系统"的业务逻辑和技术架构是通用模型，不绑定某种语言。你完全可以把数据库表结构搬到 Django + DRF 上，或者用 ThinkPHP 重新实现一套管理端。不过我还是建议，如果时间允许，尽量用 Spring Boot 当主力方案，理由有三点：第一，Spring Boot 的自动装配和 starter 机制让开发效率极高；第二，国内中小型互联网公司大面积使用 Java 技术栈，这个项目写到简历上，面试官的正向认同感会更强；第三，Spring 生态中 Spring Security、Spring Data Redis、MyBatis-Plus 等组件的整合方案成熟，遇到问题网上一搜就能找到解决方案。
2.2 Spring Boot 版本与 JDK 的配对问题
这里必须认真提醒一句：Spring Boot 版本不是越高越好，尤其是在做毕业设计的环境里。我在搜索相关资料的时候看到最近热词里频繁出现"springboot版本太高"这个说法，实际上就是很多同学直接用 IDEA 默认拉取了最新版 Spring Boot（比如 3.x），结果发现本地 JDK 还是 1.8，一堆依赖不兼容，项目根本起不来。
如果你本地安装的是 JDK 8，最稳妥的选择是 Spring Boot 2.7.x 系列；如果你电脑上装的是 JDK 17，才建议直接选 Spring Boot 3.x。Spring Boot 3.0 是一个分水岭，它基于 Jakarta EE 9 规范，很多包名从 javax.* 改成了 jakarta.*，如果你还在用老教程里的代码，会有大量 import 报错。做毕设的原则永远是"稳定优先、不折腾"，能用 2.7.18 就不要追新。等项目跑通了、论文写完了，你再去研究新版本的特性也不迟。
下面给出一个我在本地验证过的组合配置：
- JDK：1.8（对应 Spring Boot 2.7.18）
- 数据库：MySQL 5.7 或 8.0
- Redis：任意 5.x 以上版本
- 构建工具：Maven 3.6.3 以上
- ORM：MyBatis-Plus 3.5.x
- 权限认证：Spring Security + JWT
这套组合的好处是每个组件的文档都极其丰富，遇到坑有海量解决方案，不会卡在环境问题上消耗时间。
2.3 小程序端：为什么一定要加微信小程序
毕业设计要出彩，纯粹的后台管理系统已经很难打动评审老师了。现在的需求趋势是"管理端 + 用户端"双端齐全，而用户端的最佳载体就是微信小程序。微信小程序有几个天然优势：第一，不需要用户下载安装 App，扫码即用，演示时体验顺畅；第二，小程序开发工具自带模拟器和调试面板，前端调试门槛比原生 Android/iOS 低得多；第三，微信生态提供了完整的登录体系（wx.login 获取 code，后端用 code 换 openid），这本身就是答辩时可以展开讲的鉴权知识点。
在小程序端，我实现了秘境主题浏览、场次查看、在线预约、订单管理、个人中心、评价提交这几个核心页面。技术层面用了微信官方原生框架，没有额外引入 uni-app 或 Taro，原因是毕设项目功能量级不大，原生框架足够，而且可以少学一套抽象层，降低理解和排错成本。小程序端和后端通过 HTTP 接口通信，接口统一走 /api 前缀，返回 JSON 数据格式统一为 { code, message, data }，这样两端联调时不会因为字段命名不同反复返工。
2.4 单片机扩展：一个让答辩老师眼前一亮的"硬件加分项"
这里专门说说热词里反复出现的单片机。很多同学以为单片机课程设计和 Web 毕设是两件毫无关系的事，但在"秘境逃脱"这个场景里，它们天然可以融合。你可以设计一个基于 51 单片机或 ESP8266/ESP32 的室内门控设备，通过继电器控制电磁锁，当后台预约订单核销成功后，服务端向设备端发送开锁指令，玩家才能进入密室房间。整个流程就变成了完整的物联网闭环：用户线上预约 → 到店签到 → 服务端下发指令 → 单片机驱动电磁锁 → 玩家进入。
如果时间有限或者对硬件不熟悉，至少可以在系统里预留设备管理表和状态接口，在论文里写"系统预留了硬件设备接入能力，支持通过串口或 HTTP 协议与单片机通信"。这一句话，就能让答辩老师看到你技术视野的广度。我在下面第 4 章会给出具体的接入思路和关键代码，手把手教你打通 Web 端与单片机之间的通信链路。
3. 系统设计与核心功能落地
3.1 角色与权限设计
秘境逃脱管理系统的角色权限设计，我按"平台-商家-用户"三层授权模型来做。超级管理员拥有全部权限，包括商家入驻审核、主题上架下架、全局参数设置、平台运营数据查看；商家管理员只能操作自己门店的数据，包含门店信息修改、密室主题维护、场次库存调整、核销玩家订单、查看门店营收；普通用户只有小程序端的浏览、预约、取消、评价权限。
权限实现上，我选择了 Spring Security + JWT 的方案，没有直接用 Shiro，因为 Spring Security 和 Spring Boot 集成更丝滑，且社区资料丰富。JWT 令牌在用户登录成功后由后端签发，包含了用户 ID、角色信息、过期时间，小程序端把 token 存在本地缓存中，每次请求在请求头里带上 Authorization: Bearer
这里有一个实操心得：不要一开始就追求"按钮级权限"或者"数据字典级复杂权限"，对毕设来说不划算。把角色和接口的粗粒度权限做好，已经足够展示你的工程能力了。万一答辩老师追问"如果同一个商家拥有多家门店怎么办"，你可以回答说在商家管理员的 token 里追加 storeId，数据层查询时强制追加 storeId 过滤条件，即可实现多门店隔离。
3.2 数据库表设计：八张核心表撑起整个业务
数据库设计是毕设论文里的重头戏，同时也是最容易扣分的地方。我建议你不要只丢一张 ER 图上去，而是要能解释每一张表为什么这么设计、字段为什么这么冗余。这套系统的核心表我拆成了八张，分别是：
- user：平台用户表，包含用户名、密码（BCrypt 加密存）、手机号、头像、用户角色、创建时间
- merchant：商家表，包含商家名称、联系人、联系电话、商家状态（待审核/通过/拒绝）、入驻时间
- theme：密室主题表，包含所属商家 ID、主题名称、主题简介、难度等级、建议人数、时长、封面图、价格、状态
- schedule：场次表，包含主题 ID、开始时间、结束时间、可预约人数、已预约人数、场次状态
- booking：预约订单表，包含订单号、用户 ID、场次 ID、预约人数、订单状态（待支付/已支付/已取消/已完成）、支付时间、核销码
- review：评价表，包含订单 ID、用户 ID、主题 ID、评分、评价内容、回复内容、创建时间
- notice：公告表，包含标题、内容、类型、发布时间、是否置顶
- device：设备表，包含设备编号、设备类型（门锁/传感器）、绑定门店 ID、在线状态、状态更新时间
重点讲讲 booking 表和 schedule 表的关系。我在设计时没有把"库存"字段放 booking 表里，而是放到 schedule 表的 remaining 字段，用已预约人数来反推剩余名额。这样做的好处是，玩家预约时只需要做一件事：更新 schedule 表的 remaining 字段，同时插入一条 booking 记录。如果放在 booking 表现场统计数量，场次多了之后查询会越来越慢；如果用单独的库存表又增加不必要的复杂度。数据库设计的原则是：能通过简单冗余解决的性能问题就不要引入额外的表和中间件。
3.3 核心业务闭环：从搜索到核销再到评价
整个系统最值的演示的逻辑是预约业务闭环。我从用户角度走一遍完整流程，你就知道每个表是怎么协同的了。玩家打开小程序，进入首页看到密室主题列表，列表每一张卡片展示了主题名称、封面图、价格、难度和评分。点击进入主题详情后，小程序调用后端接口查询该主题未来 7 天可预约的场次列表，接口的核心 SQL 逻辑是联表查询 theme 表和 schedule 表，过滤掉已满场和已结束的场次。
玩家选择一个场次、填写预约人数，点击提交预约后，后端创建一条 booking 订单，状态为"待支付"。考虑到毕设不接真实支付，我做了"模拟支付"逻辑：用户点击"确认支付"后，系统把订单状态置为"已支付"，同时减掉场次的 remaining 人数。这一步是整个系统最核心的业务逻辑，一定要在事务里完成，否则可能出现"订单创建了但库存没扣"的数据不一致问题。玩家到店后，商家在小程序或管理端输入订单的核销码，确认订单状态变为"已完成"。体验结束后，玩家可以发起评价，评价时带上评分和内容，系统把评价关联到该订单和主题上。
从搜索、浏览、预约、支付、核销到评价，每个环节都有状态流转，这比一堆独立的 CRUD 页面有意义得多。答辩时你顺着这条线讲，老师很容易理解你系统的业务能力。
3.4 三个技术亮点：JWT、Redis、定时任务
我在技术层面设计了三个可以拿出去讲"为什么这么选"的亮点，每一个都能在答辩时给你撑腰。
第一个是 JWT 无状态登录认证。相比传统的 Session 方案，JWT 天然适合小程序这类跨端场景，前端不需要维护会话标识，后端也不需要存储 Session。服务端只需要在拦截器里校验 token 的签名和过期时间，就能拿到用户身份信息。当然 JWT 有它的问题，比如 token 吊销困难，我就在系统里加了一个"修改密码后强制下线"的逻辑，把 token 版本号放进 Redis 里，校验时对比版本号，这样既保留了 JWT 的优点，又缓解了它的缺点。
第二个是 Redis 缓存热点数据。密室主题列表、公告信息、首页 Banner 这类访问频率高但更新频率低的数据，非常适合放到 Redis 里做缓存。我用 Spring Cache 的 @Cacheable 注解实现，代码只需要加一行注解，查询时优先从缓存取，缓存没命中才查数据库，并回填缓存。在答辩时你可以补充说明：如果缓存和数据库数据不一致，可以通过设置过期时间来做最终一致性，这是当前互联网项目里最经典的做法，不需要复杂分布式锁。
第三个是定时清理过期未支付订单。预约场景里，玩家可能创建了订单但没有支付，如果不处理，库存会被永久占用。我用 Spring 自带的 @Scheduled 注解写了一个定时任务，每 5 分钟扫描一次超过 15 分钟未支付的订单，把状态更新为"已取消"，同时把场次的已预约人数减回去。这既保证了库存释放，又不需要引入消息队列，对于毕设项目来说足够优雅。
4. 实操过程与核心代码实现
4.1 环境准备与项目初始化
你拿到源码后第一步不是急着看代码，而是先把环境准备到位。我建议按下面的顺序来操作：
安装 JDK 8。如果你之前装过更高的 JDK 版本，也不用卸载，直接在 IDEA 里给项目设置 Project SDK 为 1.8 即可。安装 MySQL 5.7 或 8.0，并新建一个名为 mijing 的数据库，字符集选 utf8mb4。安装 Redis，Windows 用户可以直接下载 Microsoft 的 Redis 发行版，Mac 用户建议用 Homebrew 安装。装好后启动 Redis 服务，默认端口 6379 即可。安装 Maven，并在 IDEA Setting 里配置好本地仓库和阿里云镜像，这一步极其重要，否则下载依赖会慢到让你怀疑人生。
用 IDEA 打开项目后，Maven 会自动拉取依赖。首次加载可能需要几分钟，如果网络不好，可以修改 settings.xml 里的 mirror 为阿里云 maven 仓库。等待依赖加载完成后，修改 application.yml 里的数据库账号密码为自己本地的配置，然后运行 MijingApplication.java 的 main 方法。启动后访问 http://localhost:8080/api/check 如果能返回正常 JSON，说明后端已经起来了。
yaml复制server:
port: 8080
spring:
datasource:
url: jdbc:mysql://localhost:3306/mijing?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
username: root
password: 123456
driver-class-name: com.mysql.cj.jdbc.Driver
redis:
host: localhost
port: 6379
database: 0
jackson:
date-format: yyyy-MM-dd HH:mm:ss
time-zone: GMT+8
mybatis-plus:
mapper-locations: classpath:mapper/*.xml
configuration:
map-underscore-to-camel-case: true
log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
4.2 MyBatis-Plus 逆向工程快速生成代码
我不建议你从零手写一遍实体类、Mapper、Service，效率太低还容易出错。项目里我保留了 MyBatis-Plus 的代码生成器，你可以直接运行 CodeGenerator.java，修改数据库连接信息和表名前缀，就可以自动生成所有表的实体类、Mapper 接口和 XML 文件。生成完之后再根据自己的业务调整 Service 层，这样能把更多精力放在核心业务逻辑上。
MyBatis-Plus 有几点需要特别注意：实体类的 @TableName 注解对应表名，如果表名和类名不一致一定要显式指定；主键策略用 @TableId(type = IdType.AUTO) 匹配 MySQL 自增主键；逻辑删除字段建议用 @TableLogic 注解，做删除操作时会自动变成 UPDATE 语句而不是 DELETE，这样能保住数据，防止误删导致排查困难。这些细节在答辩时可以主动提一嘴，说明你了解生产环境的规范。
4.3 用户登录模块：JWT 鉴权完整流程
登录模块是整套系统的入口，也是安全性的门面。我先说实现流程：小程序端调用 wx.login 获取临时 code，把 code 传给后端 /api/auth/login 接口，后端拿着 code 调用微信接口换区 openid，如果该 openid 没注册过，则自动注册一个新用户，然后签发 JWT token 返回给前端。Web 管理端则是另一种方式，商家或超管输入用户名密码，后端用 BCrypt 校验密码，比对成功后签发 token。
下面是核心的 JWT 工具类部分代码，我在一个真实项目里验证过很多次，可以直接用：
java复制@Component
public class JwtUtil {
@Value("${mijing.jwt.secret}")
private String secret;
@Value("${mijing.jwt.expire}")
private Long expire;
public String generateToken(Long userId, String role) {
Date now = new Date();
Date expireDate = new Date(now.getTime() + expire * 1000);
return Jwts.builder()
.setHeaderParam("alg", "HS256")
.claim("userId", userId)
.claim("role", role)
.setIssuedAt(now)
.setExpiration(expireDate)
.signWith(SignatureAlgorithm.HS256, secret)
.compact();
}
public Claims parseToken(String token) {
return Jwts.parser()
.setSigningKey(secret)
.parseClaimsJws(token)
.getBody();
}
}
这里要提醒一点：JWT 的密钥不能硬编码在代码里提交，尤其是你将来要把项目挂到 GitHub 上。正确做法是放到 application.yml 里，用 @Value 注入，或者使用环境变量。项目里我也准备了 jasypt 加密配置的方案，不过对毕设来说，放到 application.yml 里已经足够了。
登录模块里还有一个高频坑：小程序端用 wx.login 获取的 code 是一次性的，只能使用一次，而且有效期只有 5 分钟。如果你用同一个 code 连续调两次后端接口，第二次一定会报错。调试时如果发现"获取登录后的微信用户失败"，八成就是这个原因。相关热词里也频繁出现"wx1cb4398e1413dce7"这种报错，这类问题基本都指向 code 失效或小程序后台配置的 AppID/AppSecret 不匹配。解决路径是：在小程序开发者后台核对 AppID 和 AppSecret，确保请求微信接口时带的参数是你自己小程序的。
4.4 预约模块：防止超卖的核心实现
预约模块是业务价值最高的模块，也是最容易被扣分的地方，所以我把防超卖的方案单独拿出来讲。如果一个场次只剩最后一个名额，但两个玩家同时提交预约，如果没有并发控制，那么这两个请求都可能读到 remaining = 1，然后都减成 0，最终超卖。为了解决这个问题，我没有使用悲观锁（SELECT ... FOR UPDATE），而是采用了更轻量的防御策略：在 schedule 表里加一个 version 字段，更新库存时用乐观锁的写法。
核心 SQL 逻辑如下：
sql复制UPDATE schedule
SET remaining = remaining - 1, version = version + 1, booked = booked + 1
WHERE id = #{scheduleId}
AND remaining > 0
AND version = #{oldVersion}
当数据库受影响行数为 1 时，说明更新成功；为 0 时，说明场次已经满了，返回"本场次已满"提示。这样即便两个请求同时进来，数据库的更新语句也会串行执行，第二个请求会因为 remaining > 0 条件不满足而失败，彻底避免了超卖。
同时，在业务代码里我加了 @Transactional 注解，把更新场次库存和创建订单放在同一个事务中，任何一个步骤失败都会整体回滚，保证数据一致性。这里有一个我踩过的坑：Spring 的 @Transactional 默认只在 RuntimeException 上回滚，如果你在方法里 new Exception() 抛出受检异常，事务可能不会回滚。所以项目里我统一用了自定义的 BizException 继承 RuntimeException，这样事务回滚行为就可以预期。
4.5 小程序端对接：登录与接口请求封装
小程序端的核心代码我分为两个部分：请求封装和页面逻辑。请求封装我单独写在 utils/request.js 里，统一设置 baseURL、超时时间、请求头 token，并且封装了响应拦截逻辑。每次请求前从本地缓存中取出 token，放到 header 里；收到响应后，如果 code 为 401，说明 token 过期，自动跳转登录页。
这里有一个小程序特有的细节：在小程序开发者工具里，你可能会遇到"不在以下 request 合法域名列表中"的报错。这个问题是因为微信小程序出于安全限制，要求所有 HTTP 请求的域名必须在小程序后台配置为合法域名。开发调试阶段，你可以勾选开发者工具右上角"详情-本地设置-不校验合法域名"来规避；但上线前一定要配置 HTTPS 的 request 合法域名，否则真机无法请求。我在指导同学的时候，至少有一半的人在这个问题上卡过，花一整天找不出原因，其实就是一个小勾选。
再补充一个获取用户信息的踩坑点。最近微信调整了用户隐私政策，wx.getUserProfile 接口的返回逻辑发生了很大变化。如果你在小程序端发现拿不到用户头像和昵称，不要死磕，较新的微信版本在用户点击头像昵称填写能力上做了集中收敛。我的建议是：登录流程只依赖 wx.login 获取 openid，头像昵称等资料放到个人中心让用户手动填写辅助信息，这样既避免了隐私合规问题，又保证了登录流程稳定。
4.6 单片机联动：从串口到 HTTP 的设备接入思路
如果你把单片机设备接进来，这一步会是整个项目中差异化最强的亮点。我以 ESP8266 为例，说明一下接入思路：ESP8266 通过继电器模块连接电磁锁，平时电磁锁处于闭合状态，当服务端需要开门时，向前端小程序或后台管理端推送一个"开门"事件，再由后端调用一个 HTTP 接口向 ESP8266 发送指令。
具体实现上，ESP8266 的代码里需要配置 WiFi 连接和目标服务器地址，然后周期性地向后端接口上报设备状态。后端收到开锁命令时，请求 ESP8266 提供的控制端口，ESP8266 在收到特定 JSON 指令后，把 GPIO 引脚拉高，继电器吸合，电磁锁打开。下面是用 Arduino 语法写的简易示例：
cpp复制#include <ESP8266WiFi.h>
#include <ArduinoJson.h>
const char* ssid = "your_wifi";
const char* password = "your_password";
WiFiServer server(8088);
void setup() {
pinMode(D1, OUTPUT);
digitalWrite(D1, LOW);
WiFi.begin(ssid, password);
server.begin();
}
void loop() {
WiFiClient client = server.available();
if (client) {
String request = client.readStringUntil('\n');
if (request.indexOf("open_door") >= 0) {
digitalWrite(D1, HIGH);
delay(3000);
digitalWrite(D1, LOW);
}
}
}
把这个代码烧录到 ESP8266 后，设备会连接 WiFi 并监听 8088 端口。后端想要开门时，只需要向设备的 ip:8088 发送一个包含 open_door 的 HTTP 请求。你可以用 Java 的 HttpClient 来完成这一步，或者更简单地，在管理端点击"开门"按钮后，用后端向设备的接口发起一次 HTTP 调用。
单片机设备接入这块，我要特别提醒几个硬件坑：电磁锁的驱动电压通常比较高，不能直接接在 ESP8266 的 GPIO 上，必须通过继电器模块隔离；如果设备在局域网内测试，一切正常，但一旦换了网络环境，设备的 IP 就会变化，所以生产环境中你需要让设备在启动时把自身 IP 上报到后端，而不是在代码里写死；如果你用的是 51 单片机而不是 ESP8266，那它没有自带 WiFi 功能，需要外接 ESP-01 模块或者使用串口转 WiFi 模块，此时后端控制地址也变成模块的 IP。
5. 常见问题与毕设答辩避坑
5.1 项目跑不起来的经典原因
我帮很多同学远程排查过项目启动失败的问题，总结下来 80% 的启动失败集中在三个原因。第一个是端口被占用，大家都喜欢用 8080，但如果你开了多个 Spring Boot 项目或者装了其他 Web 服务，端口冲突就很容易发生。解决方式很简单：在配置里把 server.port 改成一个不常用的端口，比如 8088。第二个是数据库连接失败，检查 MySQL 是否启动、账号密码是否正确、数据库名是否和配置里写的一致。第三个是 Redis 没有启动，很多同学项目启动时报错"Unable to connect to Redis"，一脸懵不知道怎么处理，其实只要把 Redis 服务启动起来就行。
如果你用的是 Spring Boot 3.x + JDK 17 的组合，启动时遇到类找不到的问题，很可能是版本兼容性问题。检查一下 spring-boot-starter-parent 的版本号是否符合你的 JDK，Jakarta 相关的 import 是否都从 javax 换成了 jakarta。这些都是网上社区里反复讨论的"springboot版本太高"问题的典型表现。
我把排查步骤整理成一个速查表，方便你对照操作：
| 异常表现 | 常见原因 | 解决方案 |
|---|---|---|
| 启动报端口占用 | 8080 被其他进程占用 | 换端口或杀掉占用进程 |
| 数据库连接失败 | 密码错误或数据库未启动 | 修改配置并启动 MySQL |
| Redis 连接超时 | Redis 服务未启动 | 启动 Redis 服务 |
| 依赖下载失败 | 未配置国内镜像 | 配置阿里云 Maven 镜像 |
| import javax 找不到 | Spring Boot 3.x 用了 jakarta | 改成 jakarta 包或降级到 2.x |
| 中文乱码 | 数据库字符集不对 | 统一使用 utf8mb4 |
5.2 部署打包：本地能跑和部署上线是两码事
毕设项目如果只停留在本地运行，答辩时总感觉少了点说服力。我建议至少完成一次打包部署，把系统跑在云服务器或者你自己的电脑上，然后通过公网地址访问。打包过程不算复杂，但有几个坑需要提前避开。
先用 Maven 执行 mvn clean package -DskipTests，如果一切正常，target 目录下会生成一个 jar 包。直接在服务器上执行 java -jar mijing-0.0.1-SNAPSHOT.jar 就能运行。但如果你直接把项目里的 application.yml 拿到生产环境用，多半会出问题。你需要改三处：数据库地址改成云服务器的内网或公网地址，Redis 地址改成部署环境地址，JWT 密钥换成自己的随机字符串。
小程序端如果在真机上请求接口，还有两个额外的配置。第一，你需要在微信小程序后台配置 request 合法域名，而且必须是 HTTPS 域名，这意味着你的服务器需要配置 SSL 证书。第二，如果你只是在本机测试，可以用局域网 IP 和真机调试模式，绕过域名校验，但真机预览时必须保证手机和电脑在同一网络下。很多同学部署完发现小程序访问不了接口，十有八九是忽略了 HTTPS 域名这一条。
我个人的建议是：性价比最高的部署方案是买一台 2C2G 的轻量云服务器，安装一个宝塔面板，用 Docker 把 MySQL、Redis、Spring Boot 应用都跑起来。整个过程大概半天时间，却能在答辩时让你的系统演示从"本地运行"提升到"在线可访问"，这个感知差异是非常明显的。
5.3 答辩现场高频问题与应答思路
答辩环节最考验的是你对系统的理解深度。根据我以往的经验，老师最喜欢问的问题集中在技术选型、数据一致性、安全性、扩展性这四类上。我整理了几个高频问题，并给出一种可以参考的回答结构。
"为什么选择 Spring Boot？"重点是回答自动装配、内嵌服务器、生态丰富、学习成本低，同时说明你对比过 SSM 架构和 Spring Boot 的差异，感受到了配置简化的好处。不要只说"因为大家都在用"，要有自己的理解。
"预约量大了怎么办？"这个问题考察的是你对并发和扩展性的理解。你可以回答：当前方案使用乐观锁保证不超卖，这已经能应对大部分中小型门店的并发量；如果要进一步扩展，可以引入消息队列削峰，把预约请求异步化，同时用 Redis 做更细粒度的库存预扣，再配合数据库最终扣减。"当前方案能应对什么量级、如果要扩展怎么改"这个回答结构会让老师觉得你考虑得很全面。
"数据库为什么这么设计？"建议从业务出发解释每一张表的职责，说明通过冗余字段减少 join，通过状态字段记录生命周期，通过唯一索引防止重复提交。把 3.2 节的内容重新组织一下，理清"内存关系"和"外键关系"，并说明为保持灵活性，哪些地方有意不建外键约束，而是通过应用层控制引用完整性。
"前端小程序怎么保证安全？"可以从三个方面回答：小程序端不能完全信任，所有关键操作必须由后端做鉴权和校验；登录凭证使用 code 换 openid，不暴露用户敏感信息；管理端接口统一通过 JWT 校验角色权限，防止越权访问。如果老师追问，还可以补充参数校验和 SQL 注入防护。
结束语
最后再分享一点我个人的体会。毕业设计真正难的地方往往不在写代码，而在于很多人拿到题目之后不知道从哪里下手。秘境逃脱管理系统这个项目，我把所有前期踩坑和最终可运行的源码都整理成了可以直接使用的版本，同时把每一步的设计逻辑也在文章里做了拆解，目的就是让你少走弯路，把时间花在真正理解业务和技术上。
如果你决定用这个项目，我的建议是：第一遍先不看代码，把第 3 章的业务流程和数据表读懂，在纸上画一遍预约闭环；第二遍再打开代码，对照着第 4 章的核心模块逐段理解；第三遍再尝试自己改一个小功能，比如加一个优惠券模块或者做一个数据大屏。三遍下来，这个项目才会真正长在你身上，答辩的时候不管老师怎么追问，你都能接得住。祝顺利。