写在前面为什么宿舍管理系统会成为 Java 毕设的“常青树”如果你最近在逛毕设选题库、刷技术社区应该会频繁看到“java springboot基于微信小程序的学生宿舍寝室管理系统”这个项目。它确实是这几年来 Java 方向出镜率极高的一个完整项目原因很简单业务场景贴近校园生活技术栈主流功能边界清晰做出来既能跑通全流程又能在答辩时有话可讲。我之前带过几届学生的课程设计和毕业设计宿舍管理系统几乎每隔几届就会有人选。它不像电商系统那样业务复杂、涉及支付退款也不像纯粹的管理后台那样没有“前端交互亮点”。宿舍管理天然包含三类角色学生、宿管员、系统管理员、三类核心业务住宿分配、报修处理、日常查寝再加上卫生评比、访客登记、水电费统计这些可扩展模块既能体现 CRUD 基本功又能展示权限设计、接口联调、微信登录等进阶能力。这篇内容我打算完整拆解这个系统的设计思路、技术选型、数据库建模、核心接口实现、小程序端联调以及我在实际带队过程中遇到的典型问题和排查方法。你可以把它当作一篇项目复盘来读也可以当作从零搭建同类系统的操作指南。如果你正打算做这个题目的毕设或者想找一个能练手 Spring Boot 小程序的完整项目这篇应该能帮你省下不少弯路。1. 需求拆解与整体方案设计1.1 为什么是“Spring Boot 微信小程序”这个组合先说技术选型。前端选微信小程序而不是传统 Web 页面是因为宿舍管理系统的真实使用场景是移动端学生要查寝室分数、提交报修、扫码登记宿管员要在楼栋里巡逻时完成查寝记录。如果这些操作都要求回办公室开电脑登录网页那系统就失去了实际价值。而小程序相比独立 App 最大的优势是不用安装、用完即走加上微信身份体系可以直接复用非常适合这种低频但刚需的工具型应用。后端选 Spring Boot 的原因更直接它在 Java 生态里已经成了事实标准。自动配置机制让项目启动不需要繁琐的 XML 配置内嵌 Tomcat 让部署变成“一个 jar 包跑起来”配合 Spring MVC 做接口层、MyBatis-Plus 做数据访问层写起来非常顺手。从就业角度来说Spring Boot 是几乎所有 Java 岗位的必备技能做这个项目就等于把简历上“熟练掌握 Spring Boot”这句话坐实了。你可能看到热搜词里有“springboot版本太高”“springboot配置”这类词条我多说一句版本选择上不要盲目追新在这个项目里用 Spring Boot 2.7.x 是比较稳的配套的 MyBatis-Plus、Redis 客户端等依赖兼容性都验证过了。虽然 3.x 也早就发布了但它要求 JDK 17 起步而且部分老教程的配置方式已经不适用新手在 3.x 上踩坑的概率要大不少。1.2 角色划分与功能清单宿舍管理系统的核心是三个角色功能设计也都围着这三个角色转。学生端微信小程序主要做这些事情微信授权登录自动识别学号身份查看自己的宿舍分配信息、室友信息提交宿舍报修水、电、门锁、家具等跟踪报修进度查看每日/每周卫生检查得分与扣分明细查看楼栋公告、学校通知线上请假登记晚归/外宿供宿管员审核宿管员端小程序或管理后台主要做这些事情卫生检查打分按房间维度录入分数和扣分项查寝登记记录在寝/未归/请假状态处理学生报修工单分配维修师傅或直接标记完成审核学生的请假申请访客登记与出入记录维护查看本楼栋的入住情况统计管理员端Web 管理后台主要做这些事情学生信息管理导入、新增、修改、分配宿舍楼栋/宿舍/床位的基础数据维护宿管员账号分配与权限管理全系统数据统计报表入住率、报修完成率、卫生评分趋势公告发布与维护这样划分下来系统的业务闭环就清晰了学生发起请求 → 宿管员处理日常事务 → 管理员做全局配置和数据看板。三个角色各司其职代码层面就体现在多端接口设计和权限拦截上。1.3 为什么这个系统适合当毕设项目我接待过不少学生问“这个系统会不会太简单了能不能过盲审”我的看法恰恰相反它的“简单”是表面上的真正做好需要很多细节。CRUD 只是地基往上还有登录凭证怎么管、宿舍分配冲突怎么处理、报修状态机怎么流转、报表数据怎么聚合。这些思维训练比单纯的“高并发项目”更贴合毕设的考察目标因为评审老师看的是你把一个完整业务做扎实的能力而不是堆砌一堆华而不实的技术名词。展开来说它的“含金量”体现在四个层面业务完整从用户登录到管理端数据统计是一条完整的链路不残缺。角色权限可深挖可以用拦截器做也可以用 Spring Security / Sa-Token 做写成亮点。前后端分离 小程序展示的是当前企业开发的主流形态不是老掉牙的 JSP。可扩展性强加个水电表接口、加个消息推送、加个宿舍调换审批流都是顺理成章的延伸。所以别担心这个题目“太普通”关键是你怎么把它讲出层次感。下面从技术细节开始逐步拆解。2. 核心技术与关键依赖选型2.1 Spring Boot 项目骨架搭建与版本选择我建议用 IDEA 直接创建 Spring Initializr 项目Java 版本选 JDK 8 或 JDK 11配合 Spring Boot 2.7.x打包方式选 jar。依赖方面核心就四个Spring Web提供 RESTful 接口能力MyBatis-Plus数据持久层增强工具MySQL Driver MySQL 8.0数据存储Lombok减少实体类样板代码如果要加 Redis 做 Token 缓存那就再引入 spring-boot-starter-data-redis。这里有个经验之谈很多新手一上来就塞一堆依赖什么 Druid 连接池、Swagger、Knife4j、Lombok 全加上结果启动报错都不知道找哪个。我的建议是分步来先把项目跑通再逐步加组件每一步加完都启动验证一遍这样排查问题范围小很多。MyBatis-Plus 在这个项目里确实值得用。它的 BaseMapper 直接提供了单表的 CRUD 方法像学生表、宿舍表的增删改查一行 SQL 都不用写。复杂一点的统计查询用它的 LambdaQueryWrapper 也能搞定不用手拼 XML。不过要提醒一句多表关联查询最好还是自己写 SQL放在 XML 或者注解里不要依赖 MP 的连表能力。2.2 小程序端的框架选择与工程初始化小程序端有两个选择原生微信小程序开发或者用 uni-app 跨端框架。从毕设项目角度我建议直接用原生没必要为了“跨端”增加一层抽象。原生的好处是调试直观、微信开发者工具支持好、网上资料多出现问题容易找到解决方案。如果你用 HBuilderX 开发 uni-app 项目发行到微信小程序时需要注意在 HBuilderX 里配置 manifest.json 中的微信小程序 AppID然后“发行 → 小程序-微信”把生成的 dist/build/mp-weixin 目录用微信开发者工具打开。这一步常见的问题是路径引用不对、AppID 填错导致无法预览我会在常见问题部分细说。小程序端我通常这样组织目录/miniprogram /pages /login 登录页 /home 首页公告个人宿舍信息 /repair 报修模块提交记录列表 /hygiene 卫生查询 /leave 请假申请 /profile 个人中心 /utils request.js 封装 wx.request 请求 auth.js 登录凭证管理 /components ...这种按业务功能划分的方式在答辩时讲页面结构会很清晰每个页面对应哪个业务一目了然。2.3 Redis 在项目里的实际定位热搜词里出现了“redis在springboot中的使用”正好这个项目里也用得上。宿舍管理系统的登录场景天然适合 Redis 发挥作用微信小程序端每次请求要携带登录凭证后端要根据凭证识别是哪个用户。如果用传统 Session 方案小程序端对 Cookie 的管理很别扭用 JWT 虽然能无状态但学生端没法手动让“我的登录提前过期”或“强制下线”。所以这里我更喜欢用“token 存 Redis 拦截器校验”的方案学生在小程序端调用 wx.login 拿到 code发送给后端后端调微信接口用 code 换 openid就是热词里说的“code换token”查数据库找到对应用户生成一串随机 token以 token 为 key、用户 id 为 value 写入 Redis同时设置过期时间前端后续请求都在 header 里带上 token后端拦截器统一校验这个方案的优点是后端可以在任何时刻删除某个 key 来实现“强制下线”可以统一控制过期时间而且对多端登录态的管理比纯 JWT 灵活。代价是多一次 Redis 网络开销但在这个业务量级下完全不是问题。需要注意的是 Redis 的 key 要设置过期时间建议 24 小时到 7 天之间。学生端的体验是“长时间不用需要重新登录”这是可以接受的。宿管员和管理员端的 token 可以单独设置更长的时间。3. 数据库设计与核心表结构数据库设计是答辩时老师最喜欢深挖的部分你要能讲清楚每一张表的用途、表之间的关系、为什么这么设计。宿舍管理系统至少要包含以下核心表以最核心的几张为例说设计思路学生表student字段包括 id、学号、姓名、性别、手机号、班级、宿舍 id、角色标识等。其中宿舍 id 是外键指到宿舍表。这里有一个细节很多人忽略学生表里加一个“入住状态”字段标记“已分配/未分配/已退宿”比单纯靠宿舍 id 是否为空来判断更严谨。因为学生申请调换宿舍时可能需要先“迁出”再“迁入”中间态需要能表达。宿舍表dormitory字段包括 id、楼栋号、房间号、床位数、已住人数、房间类型4人间/6人间/8人间。注意已住人数不要每次都 count 学生表可以在分配/退宿时维护这个字段也可以在查询时用多表聚合算出来。前者性能好但需要保证数据一致性后者逻辑简单但大数据量下略慢。宿舍管理系统数据量不大直接用聚合查询就行省得维护冗余字段。报修表repair_order字段包括 id、学生 id、宿舍 id、报修类型水/电/家具等、问题描述、图片地址、状态待处理/处理中/已完成/已取消、提交时间、处理人、处理时间、处理备注。这张表建议加一个索引在“状态”字段上因为宿管员端最常见的操作就是“查所有待处理的工单”。卫生检查表hygiene_record字段包括 id、宿舍 id、检查日期、分数、扣分项明细可以用 JSON 字符串或者单独子表、检查人、备注。这里有一个设计取舍如果扣分项是固定几类地面、床铺、阳台、安全用电用独立字段或者字典表更规范如果允许自由填写存 JSON 字符串最简单。我建议用固定字段加一个备注字段的组合既方便统计又保留灵活性。查寝记录表bed_check_record字段包括 id、宿舍 id、检查日期、应到人数、实到人数、未归学生 id 列表JSON、状态正常/异常、检查人。有些系统会拆成“查寝主表 查寝明细表”但宿舍管理场景下每个宿舍每次查寝的记录量不大用 JSON 存未归名单也够用还能省去连表查询。访客登记表visitor_record字段包括 id、被访宿舍 id、访客姓名、访客手机号、来访时间、离开时间、登记人。公告表notice字段包括 id、标题、内容、发布时间、发布人、状态草稿/已发布。这几张表之间的关系是学生 n:1 宿舍报修 n:1 宿舍、n:1 学生卫生记录 n:1 宿舍查寝记录 n:1 宿舍。整体结构不算复杂但是在设计阶段要提前想清楚“查询维度”宿管员关注的通常是他负责的楼栋所以宿舍表里要有楼栋字段学生关注的是自己的宿舍所以所有业务表都要能和学生产生关联。如果你在设计表的时候能画出一张清晰的 ER 图并解释每个外键的设计原因答辩这一块基本就拿下了。我自己习惯用数据库建模工具先画图再建表能提前发现很多逻辑问题比直接写建表 SQL 返工成本低得多。4. 后端接口设计与关键逻辑实现4.1 登录认证流程的完整实现登录是整个系统的入口也是我第一次带学生做项目时发现最容易卡住的地方。小程序的登录流程和外行以为的“输入用户名密码登录”不同核心是微信的 code 换 session 机制。具体步骤是前端调用wx.login()拿到一个临时凭证 code把它发给后端POST /api/auth/login后端拿这个 code 调用微信的https://api.weixin.qq.com/sns/jscode2session接口参数需要 appid、secret、js_code、grant_typeauthorization_code。微信返回的数据里最关键的是 openid这是用户在你这一个小程序里的唯一标识。如果用户之前登录过就直接查库匹配如果是第一次可能要在库里创建一个新的学生账号或者提示用户绑定学号。这里就是热词里提及的“微信小程序用 code 换 token”场景严格来说code 换的是 openidtoken 是你自己生成的登录凭证。当你在面试时把这个过程说清楚面试官基本就知道你是真做过而不是背的。在application.yml中需要配置小程序的 appid 和 secret注意不要把 secret 暴露在前端代码里只能放在后端。核心代码如下RestController RequestMapping(/api/auth) public class AuthController { Autowired private StringRedisTemplate redisTemplate; Autowired private StudentService studentService; PostMapping(/login) public Result login(RequestBody LoginRequest request) { // 1. code 换 openid String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code request.getCode() grant_typeauthorization_code; String response restTemplate.getForObject(url, String.class); JSONObject json JSON.parseObject(response); String openid json.getString(openid); if (openid null) { return Result.error(微信登录失败); } // 2. 查库找到用户 Student student studentService.findByOpenid(openid); if (student null) { // 第一次登录提示绑定学号 return Result.error(USER_NOT_FOUND, openid); } // 3. 生成 token 并存入 Redis String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(login:token: token, String.valueOf(student.getId()), 24, TimeUnit.HOURS); return Result.success(new LoginVO(token, student)); } }拦截器里校验 token 的逻辑也不复杂对需要登录的接口从 header 里取 token 字段然后在 Redis 里检查是否存在。不存在就返回 401存在就继续放行。注意给 Swagger 或小程序端“无需登录”的接口放行比如登录接口本身。4.2 宿舍分配与调换的并发考虑宿舍分配这个功能看着简单但存在一个典型的并发问题剩余 1 个床位同时两个学生都在分配怎么办如果只是简单的“先查后写”两个事务都查到剩余 1 个床位都做插入结果就会超员。解决这个问题有几种思路在宿舍表加一个“已住人数”字段分配时使用原子更新的方式UPDATE dormitory SET used used 1 WHERE id ? AND used capacity。如果 SQL 返回的影响行数为 0说明宿舍满了提示换一间。这是最简单有效的方案。使用数据库悲观锁SELECT ... FOR UPDATE锁住宿舍行再判断床位。逻辑直观但是锁的粒度较大性能一般。对于宿舍管理这种低频操作来说倒是不算问题。使用 Redis 分布式锁或者乐观锁版本号。分布式锁在这里有一点过度设计杀鸡用牛刀了。我推荐方案一原因很简单一条 SQL 解决原子性问题不引入额外复杂度。答辩时老师可能会问“你考虑过并发吗”你把这个方案讲出来加分效果很明显。4.3 报修工单的状态机流转报修工单的状态流转也是一个值得拿出来讲的设计点。我把状态定义为四个待处理0、处理中1、已完成2、已取消3。前端的按钮会根据当前状态决定可执行的操作待处理学生可以取消宿管员可以标记“处理中”处理中宿管员可以标记“已完成”学生不能操作如果学生误报了可以先取消或者联系宿管已完成双方都只能查看已取消流程终止在代码层面我建议在 Service 层做一个状态校验防止非法的状态跳转。比如public void updateStatus(Integer orderId, Integer fromStatus, Integer toStatus, Long userId) { // 校验当前状态等于 fromStatus 才允许转换 int rows repairOrderMapper.updateStatusIfMatch(orderId, fromStatus, toStatus, userId); if (rows 0) { throw new BusinessException(操作失败工单状态已变更请刷新后重试); } }这里的updateStatusIfMatch在 SQL 里带WHERE status #{fromStatus}用数据库的乐观锁机制保证状态切换的原子性。这样能避免多人同时操作同一个工单时产生状态错乱。4.4 卫生评分与统计报表怎么算卫生评分功能本身很简单就是一个表单提交。真正的难度在统计宿管员要看本周平均分、各楼栋对比、扣分项 Top3管理员要看全校的趋势变化。如果把统计逻辑全部写在 Java 里循环算不仅代码难看而且性能差。在 MySQL 里有天然的解决方案AVG()、GROUP BY、DATE_FORMAT组合。例如查每个宿舍最近一个月的平均分SELECT dormitory_id, AVG(score) AS avg_score FROM hygiene_record WHERE check_date DATE_SUB(CURDATE(), INTERVAL 1 MONTH) GROUP BY dormitory_id ORDER BY avg_score DESC;如果想统计扣分项 Top 3就把扣分项设计成几个固定字段例如deduct_floor、deduct_bed、deduct_balcony、deduct_safety然后用SUM汇总。这个需求就要求你在建表阶段考虑统计否则后面临时改表非常痛苦。这其实也是“为什么数据库设计要先想清楚查询维度”的现实案例。5. 小程序端的关键页面与联调细节5.1 登录页与身份绑定的联动逻辑小程序端的登录页交互比 Web 登录要特殊一些用户打开小程序点“微信一键登录”系统拿到 openid 去后端查库。如果用户已经绑定了学号/角色直接就进入对应的首页如果没有绑定就弹出一个“学号 姓名 班级”的绑定表单。这个绑定逻辑在毕设项目里特别重要因为如果没有绑定任何学生都能用任意微信号登录系统身份就不受控了。在真实场景里学校通常有自己的统一身份认证平台可以在这里对接毕设项目里可以简化为“初始账号密码由管理员导入学生首次用学号姓名激活绑定”。这种做法在答辩时就是完整的业务闭环。登录后的 token 要存储在小程序的 storage 里然后封装request.js在请求头里统一加上// utils/request.js const BASE_URL http://localhost:8080/api; function request(path, method, data) { return new Promise((resolve, reject) { const token wx.getStorageSync(token); wx.request({ url: BASE_URL path, method: method, data: data, header: { Authorization: token }, success: (res) { if (res.statusCode 401) { // token 过期重新登录 wx.removeStorageSync(token); wx.redirectTo({ url: /pages/login/login }); return; } resolve(res.data); }, fail: reject }); }); }5.2 顶部导航栏高度与页面适配热搜词里出现“微信小程序顶部导航栏高度”这个也是小程序开发里一个容易让人挠头的问题。不同机型的胶囊按钮位置、状态栏高度不一样如果页面用自定义导航栏高度适配没做好就会出现按钮上下错位。在宿舍管理系统的几个页面里我会用自定义导航栏来保持 UI 统一。这时可以用小程序提供的 API 动态计算const menuButton wx.getMenuButtonBoundingClientRect(); const statusBarHeight wx.getSystemInfoSync().statusBarHeight; const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height;这段代码的意思是胶囊按钮到状态栏底部的距离的两倍加上胶囊按钮本身的高度就得到了导航栏的安全高度。在开发工具里实测不同机型微信已经把适配函数封得还可以照着这个公式基本不会翻车。如果你想要更省事直接在全局样式里用系统默认导航栏就不用管这些适配了只是 UI 灵活性会差一些。5.3 前端鉴权与按钮级权限控制小程序端不只是发请求还需要处理“当前用户角色不同显示的操作不同”的问题。比如同一个页面学生看到的是“提交报修”宿管员看到的是“处理报修”。我的方案是登录成功后把用户信息也存一份到 storage 里页面渲染时根据角色判断const userInfo wx.getStorageSync(userInfo); if (userInfo.role 0) { // 学生显示提交按钮 } else if (userInfo.role 1) { // 宿管员显示处理按钮 }注意一个关键点前端的显示控制只是体验层面的真正的安全校验必须在后端做。如果后端接口没有权限校验学生直接调宿管接口也能成功那就是安全事故。所以接口层面我通常会写一个自定义注解比如RequireRole(admin)或RequireRole(dormManager)在拦截器里统一做鉴权。这样前端怎么显示无所谓后端把住关才是真安全。5.4 小程序端真机预览与域名配置本地开发的时候小程序要打开“不校验合法域名”才能访问http://localhost:8080。到了部署或者演示的时候就涉及域名配置了微信小程序要求请求域名必须是 HTTPS 且完成备案校验。如果你是在本地做毕设演示可以不管这个让微信开发者工具在“详情 → 本地设置”里勾选“不校验合法域名”。如果是要正式上线就得准备备案域名、SSL 证书并且在微信公众平台后台配置 request 合法域名。很多学生卡在这一步本机跑后端前端小程序的请求地址填的是http://localhost:8080微信开发者工具提示request:fail。大概率就是没开“不校验合法域名”选项或者是后端没启动、IP 写错。真机调试的时候需要注意手机和电脑要在同一个局域网后端地址要填电脑的局域网 IP比如http://192.168.1.100:8080不能填 localhost。6. 项目部署、文档整理与答辩技巧6.1 后端部署从 jar 包到 Docker毕设项目交付时后端部署方式会影响老师演示的顺畅程度。我推荐最稳妥的方式本地 IDEA 里直接运行 Spring Boot 主类然后把 MySQL 服务启动好再把小程序端地址指向本机。虽然不优雅但演示时出问题的概率最小。如果你想展示一点工程化能力可以写一个 Dockerfile 做容器化部署FROM maven:3.8-jdk-8 AS builder COPY . /project WORKDIR /project RUN mvn clean package -DskipTests FROM openjdk:8-jre-slim COPY --frombuilder /project/target/*.jar /app/app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, /app/app.jar]然后在服务器上用docker compose把 MySQL、Redis、Spring Boot 容器编排起来。这样做的好处是环境隔离、迁移方便答辩时还能多讲一个“容器化部署”的亮点。不过如果你的服务器内存只有 2G建议不要 MySQL Redis 应用全上光 MySQL 和 Redis 就可能吃掉一大半内存应用启动很容易变慢。6.2 文档应该包含哪些内容项目交付文档是很重要的一环很多学生重代码轻文档结果答辩时拿不出像样的材料。一份合格的宿舍管理系统文档至少要包含需求分析用例图、功能清单、非功能需求系统响应时间、并发用户数等数据库设计ER 图、每个表的字段说明接口文档每个接口的请求方法、路径、参数、返回示例系统设计架构图、模块划分、技术选型理由测试报告功能测试用例表、测试结果部署说明环境要求、启动步骤这里特别说一句接口文档不要偷懒。你用 Apifox 或者 Postman 调通了接口之后顺手把接口文档导出再整理成 Markdown 放到项目文档里。答辩时如果老师让你现场演示“报修接口怎么调用”你可以直接打开接口文档对着讲姿态就很专业。6.3 答辩常见问题预演根据我往年带队的经验宿舍管理系统答辩时高频出现的问题就那几个提前准备好能让你在讲台上从容不少“为什么选择微信小程序而不是公众号网页”从使用场景和开发成本回答。“用户的登录状态是怎么维持的”讲清楚 code 换 openid、token 存 Redis 的流程。“宿舍满了之后还能不能分配”讲清楚并发控制和剩余床位校验逻辑。“卫生评分的平均分是怎么算的”讲清楚 SQL 聚合逻辑。“如果学生换了宿舍之前的报修单怎么处理”这是一个容易被问住的点建议在报修表里冗余一个当前宿舍字段而不是通过学生 id 现查否则历史工单的宿舍信息会跟着变。最后这一点我强调一下业务表里的冗余字段不是为了炫技而是为了保留历史快照。报修单提交的时候是 301 宿舍之后学生搬到了 302之前的报修工单如果通过“学生 → 当前宿舍”现查历史记录就错了。所以我一般在报修表里直接存dormitory_id提交时写死。这个细节你在设计数据库时就可以考虑进去避免后期返工。6.4 运行视频和讲解视频怎么录如果你买的是带“运行视频 讲解视频”的套餐或者导师要求你提交演示视频录制的思路也很重要。运行视频不要从头到尾把每个页面点一遍那样又长又没重点。我建议按业务主线来录第一条主线学生端完整操作。登录 → 查看宿舍信息 → 提交一个报修 → 查看卫生评分 → 提交请假申请。第二条主线宿管员端处理操作。登录 → 看到待处理报修 → 标记处理中 → 完成工单 → 审核请假 → 录入查寝记录。第三条主线管理员端配置操作。登录 → 导入学生信息 → 分配宿舍 → 发布公告 → 查看统计数据。每条视频控制在 5 分钟内配一段语音讲解说明操作目的和背后的数据变化。这样老师看的时候能快速理解整个系统的业务流程和数据流比你录 30 分钟“无脑点页面”的效果好得多。6.5 源码结构化整理与版本控制源码的结构清晰程度会影响老师对你的第一印象。见过太多同学的代码里带了target目录、.idea目录又塞了一个test.sql和application.yml.bak整个工程乱成一团。建议交付前做一次整理删掉生成目录保留src、pom.xml、sql文件夹、README.md用 Git 管理并提交到远程仓库。README 里写清楚项目简介、技术栈、启动步骤、默认账号。这一步花不了多少时间但观感差别巨大。我自己接手过的项目中凡是 README 写得清清楚楚的后面接手的人效率至少高一倍。这不光是给老师看也是给自己留一份可复用的工程模板。7. 常见问题与排查技巧实录做项目期间踩坑是难免的我把新手最容易遇到的问题整理成一个速查表方便你遇到对症下药问题现象可能原因解决方法小程序发请求报request:fail未开启“不校验合法域名”或后端没启动开发者工具 → 详情 → 本地设置 → 勾选不校验确认 Spring Boot 启动成功登录接口返回invalid codecode 只能使用一次第二次调用就失效确保一次 wx.login 的 code 只发给后端一次不要重复调用接口 401 或 token 校验失败前端没在 header 带 token或 Redis 里 key 过期F12 看请求头确认 Authorization 字段查 Redis 的 key 是否存在MySQL 连接不上数据库没启动、账号密码错、IP 写错用命令行试连mysql -uroot -p检查 application.yml 的 urlMyBatis-Plus 查询结果为空表名和实体类名映射不上检查 TableName 注解或配置 map-underscore-to-camel-case后端 8080 端口被占用有其他进程占用端口换端口或在 IDEA 运行配置里改server.port小程序真机预览白屏请求的地址是 localhost改为电脑局域网 IP确保手机和电脑同一 Wi-Fi上传图片功能失败临时文件存储路径不存在配置上传目录启动时创建目录几个代表性的问题我展开说说。端口占用问题是高频问题。特别是你以前跑过别的项目8080 被之前的 Tomcat 或另一个 Spring Boot 进程占着启动日志里会直接报Port 8080 was already in use。在 Windows 上可以用netstat -ano | findstr 8080找到 PID然后在任务管理器里结束进程也可以用Ctrl C回 IDEA 控制台停掉之前的进程。或者干脆在application.yml里把端口换掉比如 8081一了百了。“微信小程序 code 换 token”的坑也值得单独说。微信官方文档明确说wx.login()返回的 code 只能用一次而且有效期只有 5 分钟。如果你的前端在页面onLoad里调了一次wx.login()然后用户停留了一会儿之后才点登录按钮又调了一次之前那个 code 已经没用了——如果后端拿到的是旧 code微信接口就会返回errcode: 40029。解决方案就是点击登录按钮时现场调wx.login()不要提前缓存 code。另外wx.login()不要求用户授权它只是获取临时凭证真正获取用户手机号或者个人信息才需要授权弹窗。“查询变慢”是另一种常被忽视的问题。宿舍管理系统的数据量并不大但如果报修表、卫生表越来越大WHERE dormitory_id ?的查询会越来越慢。解决方案就是加索引比如idx_dormitory_id、idx_status、idx_check_date。你可以在设计表的时候就把这些索引加上也可以在写 SQL 时用 EXPLAIN 看执行计划再补齐。不管哪种方式能在答辩时讲出“我给 XX 字段建了索引因为查询频率高”这句话都是加分的。还有一个很容易被忽视的坑是“时区问题”。Spring Boot 连接 MySQL 8.0 时URL 需要加serverTimezoneAsia/Shanghai否则可能会报时区相关的错误。另外建议统一使用 LocalDateTime 类型而不是 Date 类型配合 Jackson 配置格式化返回给前端的时间显示会规范很多。我见过不少学生的代码返回时间是一串数字小程序端拿到之后不知道怎么格式化其实就是后端没配好。在application.yml里加一行配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这行配置能解决前端时间显示乱掉的问题别漏了。8. 做项目时的几点个人体会项目做到后半段很多人的心态会从“我要做一个系统”变成“我要把它做完交差”。这两种状态产出的东西差别很大。我带队这几年明显感觉到那些愿意从用户视角审视自己作品的人做出的项目无论代码质量还是文档完整度都高出一个档次。立一个“学习清单”是个好习惯做登录功能时顺便搞清楚 JWT 和 Session 的区别做权限拦截时顺便看看 Spring Security 的过滤器链是怎么工作的做 Redis 存 token 时顺便了解缓存穿透和过期策略的概念。这些知识在做项目的过程中顺路学一遍面试时就能作为项目经验讲出来而不是背八股文。还有一件事值得花时间把项目跑通一遍完整的业务流程后做一次“我是一名宿管员我现在站在宿舍门口要录入今天的查寝记录”这样的角色代入测试。你会发现很多设计上的不合理之处——比如“查寝记录必须逐间宿舍录入操作特别繁琐”“一个宿舍 8 个人未归名单要点 8 次才能选中”。这些体验上的问题在演示时可能不会被老师注意到但真实使用时会让人崩溃。改进这些细节的过程才是真正的产品思维训练。如果你后续想扩展这个项目方向也有很多接入企业微信消息通知宿管员处理完报修时自动通知学生做宿舍调换审批流涉及两间宿舍的状态一致性把卫生评分和文明宿舍评比结合起来生成学期排名。这些扩展既能增加项目深度也能让你在面试时有更多可以聊的亮点。就我个人经验来说做这种“完整链路”的项目最大的收获不是掌握了 Spring Boot 的某个注解而是建立了一种“从需求到落地的整局观”。你不再是一个只写代码片段的人而是可以独立完成一个产品闭环的开发者。这个能力在任何技术栈上都是通用的。最后送上一句实操建议代码写到一半跑不动的时候别急着在网上搜“为什么报错”先看控制台的最下面一行错误信息再从上往下读堆栈把“异常类型 触发位置”记下来再搜。这个习惯能让你查错的效率提升至少一倍。 Spring Boot + 微信小程序宿舍管理系统：从设计到部署全解析
写在前面为什么宿舍管理系统会成为 Java 毕设的“常青树”如果你最近在逛毕设选题库、刷技术社区应该会频繁看到“java springboot基于微信小程序的学生宿舍寝室管理系统”这个项目。它确实是这几年来 Java 方向出镜率极高的一个完整项目原因很简单业务场景贴近校园生活技术栈主流功能边界清晰做出来既能跑通全流程又能在答辩时有话可讲。我之前带过几届学生的课程设计和毕业设计宿舍管理系统几乎每隔几届就会有人选。它不像电商系统那样业务复杂、涉及支付退款也不像纯粹的管理后台那样没有“前端交互亮点”。宿舍管理天然包含三类角色学生、宿管员、系统管理员、三类核心业务住宿分配、报修处理、日常查寝再加上卫生评比、访客登记、水电费统计这些可扩展模块既能体现 CRUD 基本功又能展示权限设计、接口联调、微信登录等进阶能力。这篇内容我打算完整拆解这个系统的设计思路、技术选型、数据库建模、核心接口实现、小程序端联调以及我在实际带队过程中遇到的典型问题和排查方法。你可以把它当作一篇项目复盘来读也可以当作从零搭建同类系统的操作指南。如果你正打算做这个题目的毕设或者想找一个能练手 Spring Boot 小程序的完整项目这篇应该能帮你省下不少弯路。1. 需求拆解与整体方案设计1.1 为什么是“Spring Boot 微信小程序”这个组合先说技术选型。前端选微信小程序而不是传统 Web 页面是因为宿舍管理系统的真实使用场景是移动端学生要查寝室分数、提交报修、扫码登记宿管员要在楼栋里巡逻时完成查寝记录。如果这些操作都要求回办公室开电脑登录网页那系统就失去了实际价值。而小程序相比独立 App 最大的优势是不用安装、用完即走加上微信身份体系可以直接复用非常适合这种低频但刚需的工具型应用。后端选 Spring Boot 的原因更直接它在 Java 生态里已经成了事实标准。自动配置机制让项目启动不需要繁琐的 XML 配置内嵌 Tomcat 让部署变成“一个 jar 包跑起来”配合 Spring MVC 做接口层、MyBatis-Plus 做数据访问层写起来非常顺手。从就业角度来说Spring Boot 是几乎所有 Java 岗位的必备技能做这个项目就等于把简历上“熟练掌握 Spring Boot”这句话坐实了。你可能看到热搜词里有“springboot版本太高”“springboot配置”这类词条我多说一句版本选择上不要盲目追新在这个项目里用 Spring Boot 2.7.x 是比较稳的配套的 MyBatis-Plus、Redis 客户端等依赖兼容性都验证过了。虽然 3.x 也早就发布了但它要求 JDK 17 起步而且部分老教程的配置方式已经不适用新手在 3.x 上踩坑的概率要大不少。1.2 角色划分与功能清单宿舍管理系统的核心是三个角色功能设计也都围着这三个角色转。学生端微信小程序主要做这些事情微信授权登录自动识别学号身份查看自己的宿舍分配信息、室友信息提交宿舍报修水、电、门锁、家具等跟踪报修进度查看每日/每周卫生检查得分与扣分明细查看楼栋公告、学校通知线上请假登记晚归/外宿供宿管员审核宿管员端小程序或管理后台主要做这些事情卫生检查打分按房间维度录入分数和扣分项查寝登记记录在寝/未归/请假状态处理学生报修工单分配维修师傅或直接标记完成审核学生的请假申请访客登记与出入记录维护查看本楼栋的入住情况统计管理员端Web 管理后台主要做这些事情学生信息管理导入、新增、修改、分配宿舍楼栋/宿舍/床位的基础数据维护宿管员账号分配与权限管理全系统数据统计报表入住率、报修完成率、卫生评分趋势公告发布与维护这样划分下来系统的业务闭环就清晰了学生发起请求 → 宿管员处理日常事务 → 管理员做全局配置和数据看板。三个角色各司其职代码层面就体现在多端接口设计和权限拦截上。1.3 为什么这个系统适合当毕设项目我接待过不少学生问“这个系统会不会太简单了能不能过盲审”我的看法恰恰相反它的“简单”是表面上的真正做好需要很多细节。CRUD 只是地基往上还有登录凭证怎么管、宿舍分配冲突怎么处理、报修状态机怎么流转、报表数据怎么聚合。这些思维训练比单纯的“高并发项目”更贴合毕设的考察目标因为评审老师看的是你把一个完整业务做扎实的能力而不是堆砌一堆华而不实的技术名词。展开来说它的“含金量”体现在四个层面业务完整从用户登录到管理端数据统计是一条完整的链路不残缺。角色权限可深挖可以用拦截器做也可以用 Spring Security / Sa-Token 做写成亮点。前后端分离 小程序展示的是当前企业开发的主流形态不是老掉牙的 JSP。可扩展性强加个水电表接口、加个消息推送、加个宿舍调换审批流都是顺理成章的延伸。所以别担心这个题目“太普通”关键是你怎么把它讲出层次感。下面从技术细节开始逐步拆解。2. 核心技术与关键依赖选型2.1 Spring Boot 项目骨架搭建与版本选择我建议用 IDEA 直接创建 Spring Initializr 项目Java 版本选 JDK 8 或 JDK 11配合 Spring Boot 2.7.x打包方式选 jar。依赖方面核心就四个Spring Web提供 RESTful 接口能力MyBatis-Plus数据持久层增强工具MySQL Driver MySQL 8.0数据存储Lombok减少实体类样板代码如果要加 Redis 做 Token 缓存那就再引入 spring-boot-starter-data-redis。这里有个经验之谈很多新手一上来就塞一堆依赖什么 Druid 连接池、Swagger、Knife4j、Lombok 全加上结果启动报错都不知道找哪个。我的建议是分步来先把项目跑通再逐步加组件每一步加完都启动验证一遍这样排查问题范围小很多。MyBatis-Plus 在这个项目里确实值得用。它的 BaseMapper 直接提供了单表的 CRUD 方法像学生表、宿舍表的增删改查一行 SQL 都不用写。复杂一点的统计查询用它的 LambdaQueryWrapper 也能搞定不用手拼 XML。不过要提醒一句多表关联查询最好还是自己写 SQL放在 XML 或者注解里不要依赖 MP 的连表能力。2.2 小程序端的框架选择与工程初始化小程序端有两个选择原生微信小程序开发或者用 uni-app 跨端框架。从毕设项目角度我建议直接用原生没必要为了“跨端”增加一层抽象。原生的好处是调试直观、微信开发者工具支持好、网上资料多出现问题容易找到解决方案。如果你用 HBuilderX 开发 uni-app 项目发行到微信小程序时需要注意在 HBuilderX 里配置 manifest.json 中的微信小程序 AppID然后“发行 → 小程序-微信”把生成的 dist/build/mp-weixin 目录用微信开发者工具打开。这一步常见的问题是路径引用不对、AppID 填错导致无法预览我会在常见问题部分细说。小程序端我通常这样组织目录/miniprogram /pages /login 登录页 /home 首页公告个人宿舍信息 /repair 报修模块提交记录列表 /hygiene 卫生查询 /leave 请假申请 /profile 个人中心 /utils request.js 封装 wx.request 请求 auth.js 登录凭证管理 /components ...这种按业务功能划分的方式在答辩时讲页面结构会很清晰每个页面对应哪个业务一目了然。2.3 Redis 在项目里的实际定位热搜词里出现了“redis在springboot中的使用”正好这个项目里也用得上。宿舍管理系统的登录场景天然适合 Redis 发挥作用微信小程序端每次请求要携带登录凭证后端要根据凭证识别是哪个用户。如果用传统 Session 方案小程序端对 Cookie 的管理很别扭用 JWT 虽然能无状态但学生端没法手动让“我的登录提前过期”或“强制下线”。所以这里我更喜欢用“token 存 Redis 拦截器校验”的方案学生在小程序端调用 wx.login 拿到 code发送给后端后端调微信接口用 code 换 openid就是热词里说的“code换token”查数据库找到对应用户生成一串随机 token以 token 为 key、用户 id 为 value 写入 Redis同时设置过期时间前端后续请求都在 header 里带上 token后端拦截器统一校验这个方案的优点是后端可以在任何时刻删除某个 key 来实现“强制下线”可以统一控制过期时间而且对多端登录态的管理比纯 JWT 灵活。代价是多一次 Redis 网络开销但在这个业务量级下完全不是问题。需要注意的是 Redis 的 key 要设置过期时间建议 24 小时到 7 天之间。学生端的体验是“长时间不用需要重新登录”这是可以接受的。宿管员和管理员端的 token 可以单独设置更长的时间。3. 数据库设计与核心表结构数据库设计是答辩时老师最喜欢深挖的部分你要能讲清楚每一张表的用途、表之间的关系、为什么这么设计。宿舍管理系统至少要包含以下核心表以最核心的几张为例说设计思路学生表student字段包括 id、学号、姓名、性别、手机号、班级、宿舍 id、角色标识等。其中宿舍 id 是外键指到宿舍表。这里有一个细节很多人忽略学生表里加一个“入住状态”字段标记“已分配/未分配/已退宿”比单纯靠宿舍 id 是否为空来判断更严谨。因为学生申请调换宿舍时可能需要先“迁出”再“迁入”中间态需要能表达。宿舍表dormitory字段包括 id、楼栋号、房间号、床位数、已住人数、房间类型4人间/6人间/8人间。注意已住人数不要每次都 count 学生表可以在分配/退宿时维护这个字段也可以在查询时用多表聚合算出来。前者性能好但需要保证数据一致性后者逻辑简单但大数据量下略慢。宿舍管理系统数据量不大直接用聚合查询就行省得维护冗余字段。报修表repair_order字段包括 id、学生 id、宿舍 id、报修类型水/电/家具等、问题描述、图片地址、状态待处理/处理中/已完成/已取消、提交时间、处理人、处理时间、处理备注。这张表建议加一个索引在“状态”字段上因为宿管员端最常见的操作就是“查所有待处理的工单”。卫生检查表hygiene_record字段包括 id、宿舍 id、检查日期、分数、扣分项明细可以用 JSON 字符串或者单独子表、检查人、备注。这里有一个设计取舍如果扣分项是固定几类地面、床铺、阳台、安全用电用独立字段或者字典表更规范如果允许自由填写存 JSON 字符串最简单。我建议用固定字段加一个备注字段的组合既方便统计又保留灵活性。查寝记录表bed_check_record字段包括 id、宿舍 id、检查日期、应到人数、实到人数、未归学生 id 列表JSON、状态正常/异常、检查人。有些系统会拆成“查寝主表 查寝明细表”但宿舍管理场景下每个宿舍每次查寝的记录量不大用 JSON 存未归名单也够用还能省去连表查询。访客登记表visitor_record字段包括 id、被访宿舍 id、访客姓名、访客手机号、来访时间、离开时间、登记人。公告表notice字段包括 id、标题、内容、发布时间、发布人、状态草稿/已发布。这几张表之间的关系是学生 n:1 宿舍报修 n:1 宿舍、n:1 学生卫生记录 n:1 宿舍查寝记录 n:1 宿舍。整体结构不算复杂但是在设计阶段要提前想清楚“查询维度”宿管员关注的通常是他负责的楼栋所以宿舍表里要有楼栋字段学生关注的是自己的宿舍所以所有业务表都要能和学生产生关联。如果你在设计表的时候能画出一张清晰的 ER 图并解释每个外键的设计原因答辩这一块基本就拿下了。我自己习惯用数据库建模工具先画图再建表能提前发现很多逻辑问题比直接写建表 SQL 返工成本低得多。4. 后端接口设计与关键逻辑实现4.1 登录认证流程的完整实现登录是整个系统的入口也是我第一次带学生做项目时发现最容易卡住的地方。小程序的登录流程和外行以为的“输入用户名密码登录”不同核心是微信的 code 换 session 机制。具体步骤是前端调用wx.login()拿到一个临时凭证 code把它发给后端POST /api/auth/login后端拿这个 code 调用微信的https://api.weixin.qq.com/sns/jscode2session接口参数需要 appid、secret、js_code、grant_typeauthorization_code。微信返回的数据里最关键的是 openid这是用户在你这一个小程序里的唯一标识。如果用户之前登录过就直接查库匹配如果是第一次可能要在库里创建一个新的学生账号或者提示用户绑定学号。这里就是热词里提及的“微信小程序用 code 换 token”场景严格来说code 换的是 openidtoken 是你自己生成的登录凭证。当你在面试时把这个过程说清楚面试官基本就知道你是真做过而不是背的。在application.yml中需要配置小程序的 appid 和 secret注意不要把 secret 暴露在前端代码里只能放在后端。核心代码如下RestController RequestMapping(/api/auth) public class AuthController { Autowired private StringRedisTemplate redisTemplate; Autowired private StudentService studentService; PostMapping(/login) public Result login(RequestBody LoginRequest request) { // 1. code 换 openid String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code request.getCode() grant_typeauthorization_code; String response restTemplate.getForObject(url, String.class); JSONObject json JSON.parseObject(response); String openid json.getString(openid); if (openid null) { return Result.error(微信登录失败); } // 2. 查库找到用户 Student student studentService.findByOpenid(openid); if (student null) { // 第一次登录提示绑定学号 return Result.error(USER_NOT_FOUND, openid); } // 3. 生成 token 并存入 Redis String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(login:token: token, String.valueOf(student.getId()), 24, TimeUnit.HOURS); return Result.success(new LoginVO(token, student)); } }拦截器里校验 token 的逻辑也不复杂对需要登录的接口从 header 里取 token 字段然后在 Redis 里检查是否存在。不存在就返回 401存在就继续放行。注意给 Swagger 或小程序端“无需登录”的接口放行比如登录接口本身。4.2 宿舍分配与调换的并发考虑宿舍分配这个功能看着简单但存在一个典型的并发问题剩余 1 个床位同时两个学生都在分配怎么办如果只是简单的“先查后写”两个事务都查到剩余 1 个床位都做插入结果就会超员。解决这个问题有几种思路在宿舍表加一个“已住人数”字段分配时使用原子更新的方式UPDATE dormitory SET used used 1 WHERE id ? AND used capacity。如果 SQL 返回的影响行数为 0说明宿舍满了提示换一间。这是最简单有效的方案。使用数据库悲观锁SELECT ... FOR UPDATE锁住宿舍行再判断床位。逻辑直观但是锁的粒度较大性能一般。对于宿舍管理这种低频操作来说倒是不算问题。使用 Redis 分布式锁或者乐观锁版本号。分布式锁在这里有一点过度设计杀鸡用牛刀了。我推荐方案一原因很简单一条 SQL 解决原子性问题不引入额外复杂度。答辩时老师可能会问“你考虑过并发吗”你把这个方案讲出来加分效果很明显。4.3 报修工单的状态机流转报修工单的状态流转也是一个值得拿出来讲的设计点。我把状态定义为四个待处理0、处理中1、已完成2、已取消3。前端的按钮会根据当前状态决定可执行的操作待处理学生可以取消宿管员可以标记“处理中”处理中宿管员可以标记“已完成”学生不能操作如果学生误报了可以先取消或者联系宿管已完成双方都只能查看已取消流程终止在代码层面我建议在 Service 层做一个状态校验防止非法的状态跳转。比如public void updateStatus(Integer orderId, Integer fromStatus, Integer toStatus, Long userId) { // 校验当前状态等于 fromStatus 才允许转换 int rows repairOrderMapper.updateStatusIfMatch(orderId, fromStatus, toStatus, userId); if (rows 0) { throw new BusinessException(操作失败工单状态已变更请刷新后重试); } }这里的updateStatusIfMatch在 SQL 里带WHERE status #{fromStatus}用数据库的乐观锁机制保证状态切换的原子性。这样能避免多人同时操作同一个工单时产生状态错乱。4.4 卫生评分与统计报表怎么算卫生评分功能本身很简单就是一个表单提交。真正的难度在统计宿管员要看本周平均分、各楼栋对比、扣分项 Top3管理员要看全校的趋势变化。如果把统计逻辑全部写在 Java 里循环算不仅代码难看而且性能差。在 MySQL 里有天然的解决方案AVG()、GROUP BY、DATE_FORMAT组合。例如查每个宿舍最近一个月的平均分SELECT dormitory_id, AVG(score) AS avg_score FROM hygiene_record WHERE check_date DATE_SUB(CURDATE(), INTERVAL 1 MONTH) GROUP BY dormitory_id ORDER BY avg_score DESC;如果想统计扣分项 Top 3就把扣分项设计成几个固定字段例如deduct_floor、deduct_bed、deduct_balcony、deduct_safety然后用SUM汇总。这个需求就要求你在建表阶段考虑统计否则后面临时改表非常痛苦。这其实也是“为什么数据库设计要先想清楚查询维度”的现实案例。5. 小程序端的关键页面与联调细节5.1 登录页与身份绑定的联动逻辑小程序端的登录页交互比 Web 登录要特殊一些用户打开小程序点“微信一键登录”系统拿到 openid 去后端查库。如果用户已经绑定了学号/角色直接就进入对应的首页如果没有绑定就弹出一个“学号 姓名 班级”的绑定表单。这个绑定逻辑在毕设项目里特别重要因为如果没有绑定任何学生都能用任意微信号登录系统身份就不受控了。在真实场景里学校通常有自己的统一身份认证平台可以在这里对接毕设项目里可以简化为“初始账号密码由管理员导入学生首次用学号姓名激活绑定”。这种做法在答辩时就是完整的业务闭环。登录后的 token 要存储在小程序的 storage 里然后封装request.js在请求头里统一加上// utils/request.js const BASE_URL http://localhost:8080/api; function request(path, method, data) { return new Promise((resolve, reject) { const token wx.getStorageSync(token); wx.request({ url: BASE_URL path, method: method, data: data, header: { Authorization: token }, success: (res) { if (res.statusCode 401) { // token 过期重新登录 wx.removeStorageSync(token); wx.redirectTo({ url: /pages/login/login }); return; } resolve(res.data); }, fail: reject }); }); }5.2 顶部导航栏高度与页面适配热搜词里出现“微信小程序顶部导航栏高度”这个也是小程序开发里一个容易让人挠头的问题。不同机型的胶囊按钮位置、状态栏高度不一样如果页面用自定义导航栏高度适配没做好就会出现按钮上下错位。在宿舍管理系统的几个页面里我会用自定义导航栏来保持 UI 统一。这时可以用小程序提供的 API 动态计算const menuButton wx.getMenuButtonBoundingClientRect(); const statusBarHeight wx.getSystemInfoSync().statusBarHeight; const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height;这段代码的意思是胶囊按钮到状态栏底部的距离的两倍加上胶囊按钮本身的高度就得到了导航栏的安全高度。在开发工具里实测不同机型微信已经把适配函数封得还可以照着这个公式基本不会翻车。如果你想要更省事直接在全局样式里用系统默认导航栏就不用管这些适配了只是 UI 灵活性会差一些。5.3 前端鉴权与按钮级权限控制小程序端不只是发请求还需要处理“当前用户角色不同显示的操作不同”的问题。比如同一个页面学生看到的是“提交报修”宿管员看到的是“处理报修”。我的方案是登录成功后把用户信息也存一份到 storage 里页面渲染时根据角色判断const userInfo wx.getStorageSync(userInfo); if (userInfo.role 0) { // 学生显示提交按钮 } else if (userInfo.role 1) { // 宿管员显示处理按钮 }注意一个关键点前端的显示控制只是体验层面的真正的安全校验必须在后端做。如果后端接口没有权限校验学生直接调宿管接口也能成功那就是安全事故。所以接口层面我通常会写一个自定义注解比如RequireRole(admin)或RequireRole(dormManager)在拦截器里统一做鉴权。这样前端怎么显示无所谓后端把住关才是真安全。5.4 小程序端真机预览与域名配置本地开发的时候小程序要打开“不校验合法域名”才能访问http://localhost:8080。到了部署或者演示的时候就涉及域名配置了微信小程序要求请求域名必须是 HTTPS 且完成备案校验。如果你是在本地做毕设演示可以不管这个让微信开发者工具在“详情 → 本地设置”里勾选“不校验合法域名”。如果是要正式上线就得准备备案域名、SSL 证书并且在微信公众平台后台配置 request 合法域名。很多学生卡在这一步本机跑后端前端小程序的请求地址填的是http://localhost:8080微信开发者工具提示request:fail。大概率就是没开“不校验合法域名”选项或者是后端没启动、IP 写错。真机调试的时候需要注意手机和电脑要在同一个局域网后端地址要填电脑的局域网 IP比如http://192.168.1.100:8080不能填 localhost。6. 项目部署、文档整理与答辩技巧6.1 后端部署从 jar 包到 Docker毕设项目交付时后端部署方式会影响老师演示的顺畅程度。我推荐最稳妥的方式本地 IDEA 里直接运行 Spring Boot 主类然后把 MySQL 服务启动好再把小程序端地址指向本机。虽然不优雅但演示时出问题的概率最小。如果你想展示一点工程化能力可以写一个 Dockerfile 做容器化部署FROM maven:3.8-jdk-8 AS builder COPY . /project WORKDIR /project RUN mvn clean package -DskipTests FROM openjdk:8-jre-slim COPY --frombuilder /project/target/*.jar /app/app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, /app/app.jar]然后在服务器上用docker compose把 MySQL、Redis、Spring Boot 容器编排起来。这样做的好处是环境隔离、迁移方便答辩时还能多讲一个“容器化部署”的亮点。不过如果你的服务器内存只有 2G建议不要 MySQL Redis 应用全上光 MySQL 和 Redis 就可能吃掉一大半内存应用启动很容易变慢。6.2 文档应该包含哪些内容项目交付文档是很重要的一环很多学生重代码轻文档结果答辩时拿不出像样的材料。一份合格的宿舍管理系统文档至少要包含需求分析用例图、功能清单、非功能需求系统响应时间、并发用户数等数据库设计ER 图、每个表的字段说明接口文档每个接口的请求方法、路径、参数、返回示例系统设计架构图、模块划分、技术选型理由测试报告功能测试用例表、测试结果部署说明环境要求、启动步骤这里特别说一句接口文档不要偷懒。你用 Apifox 或者 Postman 调通了接口之后顺手把接口文档导出再整理成 Markdown 放到项目文档里。答辩时如果老师让你现场演示“报修接口怎么调用”你可以直接打开接口文档对着讲姿态就很专业。6.3 答辩常见问题预演根据我往年带队的经验宿舍管理系统答辩时高频出现的问题就那几个提前准备好能让你在讲台上从容不少“为什么选择微信小程序而不是公众号网页”从使用场景和开发成本回答。“用户的登录状态是怎么维持的”讲清楚 code 换 openid、token 存 Redis 的流程。“宿舍满了之后还能不能分配”讲清楚并发控制和剩余床位校验逻辑。“卫生评分的平均分是怎么算的”讲清楚 SQL 聚合逻辑。“如果学生换了宿舍之前的报修单怎么处理”这是一个容易被问住的点建议在报修表里冗余一个当前宿舍字段而不是通过学生 id 现查否则历史工单的宿舍信息会跟着变。最后这一点我强调一下业务表里的冗余字段不是为了炫技而是为了保留历史快照。报修单提交的时候是 301 宿舍之后学生搬到了 302之前的报修工单如果通过“学生 → 当前宿舍”现查历史记录就错了。所以我一般在报修表里直接存dormitory_id提交时写死。这个细节你在设计数据库时就可以考虑进去避免后期返工。6.4 运行视频和讲解视频怎么录如果你买的是带“运行视频 讲解视频”的套餐或者导师要求你提交演示视频录制的思路也很重要。运行视频不要从头到尾把每个页面点一遍那样又长又没重点。我建议按业务主线来录第一条主线学生端完整操作。登录 → 查看宿舍信息 → 提交一个报修 → 查看卫生评分 → 提交请假申请。第二条主线宿管员端处理操作。登录 → 看到待处理报修 → 标记处理中 → 完成工单 → 审核请假 → 录入查寝记录。第三条主线管理员端配置操作。登录 → 导入学生信息 → 分配宿舍 → 发布公告 → 查看统计数据。每条视频控制在 5 分钟内配一段语音讲解说明操作目的和背后的数据变化。这样老师看的时候能快速理解整个系统的业务流程和数据流比你录 30 分钟“无脑点页面”的效果好得多。6.5 源码结构化整理与版本控制源码的结构清晰程度会影响老师对你的第一印象。见过太多同学的代码里带了target目录、.idea目录又塞了一个test.sql和application.yml.bak整个工程乱成一团。建议交付前做一次整理删掉生成目录保留src、pom.xml、sql文件夹、README.md用 Git 管理并提交到远程仓库。README 里写清楚项目简介、技术栈、启动步骤、默认账号。这一步花不了多少时间但观感差别巨大。我自己接手过的项目中凡是 README 写得清清楚楚的后面接手的人效率至少高一倍。这不光是给老师看也是给自己留一份可复用的工程模板。7. 常见问题与排查技巧实录做项目期间踩坑是难免的我把新手最容易遇到的问题整理成一个速查表方便你遇到对症下药问题现象可能原因解决方法小程序发请求报request:fail未开启“不校验合法域名”或后端没启动开发者工具 → 详情 → 本地设置 → 勾选不校验确认 Spring Boot 启动成功登录接口返回invalid codecode 只能使用一次第二次调用就失效确保一次 wx.login 的 code 只发给后端一次不要重复调用接口 401 或 token 校验失败前端没在 header 带 token或 Redis 里 key 过期F12 看请求头确认 Authorization 字段查 Redis 的 key 是否存在MySQL 连接不上数据库没启动、账号密码错、IP 写错用命令行试连mysql -uroot -p检查 application.yml 的 urlMyBatis-Plus 查询结果为空表名和实体类名映射不上检查 TableName 注解或配置 map-underscore-to-camel-case后端 8080 端口被占用有其他进程占用端口换端口或在 IDEA 运行配置里改server.port小程序真机预览白屏请求的地址是 localhost改为电脑局域网 IP确保手机和电脑同一 Wi-Fi上传图片功能失败临时文件存储路径不存在配置上传目录启动时创建目录几个代表性的问题我展开说说。端口占用问题是高频问题。特别是你以前跑过别的项目8080 被之前的 Tomcat 或另一个 Spring Boot 进程占着启动日志里会直接报Port 8080 was already in use。在 Windows 上可以用netstat -ano | findstr 8080找到 PID然后在任务管理器里结束进程也可以用Ctrl C回 IDEA 控制台停掉之前的进程。或者干脆在application.yml里把端口换掉比如 8081一了百了。“微信小程序 code 换 token”的坑也值得单独说。微信官方文档明确说wx.login()返回的 code 只能用一次而且有效期只有 5 分钟。如果你的前端在页面onLoad里调了一次wx.login()然后用户停留了一会儿之后才点登录按钮又调了一次之前那个 code 已经没用了——如果后端拿到的是旧 code微信接口就会返回errcode: 40029。解决方案就是点击登录按钮时现场调wx.login()不要提前缓存 code。另外wx.login()不要求用户授权它只是获取临时凭证真正获取用户手机号或者个人信息才需要授权弹窗。“查询变慢”是另一种常被忽视的问题。宿舍管理系统的数据量并不大但如果报修表、卫生表越来越大WHERE dormitory_id ?的查询会越来越慢。解决方案就是加索引比如idx_dormitory_id、idx_status、idx_check_date。你可以在设计表的时候就把这些索引加上也可以在写 SQL 时用 EXPLAIN 看执行计划再补齐。不管哪种方式能在答辩时讲出“我给 XX 字段建了索引因为查询频率高”这句话都是加分的。还有一个很容易被忽视的坑是“时区问题”。Spring Boot 连接 MySQL 8.0 时URL 需要加serverTimezoneAsia/Shanghai否则可能会报时区相关的错误。另外建议统一使用 LocalDateTime 类型而不是 Date 类型配合 Jackson 配置格式化返回给前端的时间显示会规范很多。我见过不少学生的代码返回时间是一串数字小程序端拿到之后不知道怎么格式化其实就是后端没配好。在application.yml里加一行配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这行配置能解决前端时间显示乱掉的问题别漏了。8. 做项目时的几点个人体会项目做到后半段很多人的心态会从“我要做一个系统”变成“我要把它做完交差”。这两种状态产出的东西差别很大。我带队这几年明显感觉到那些愿意从用户视角审视自己作品的人做出的项目无论代码质量还是文档完整度都高出一个档次。立一个“学习清单”是个好习惯做登录功能时顺便搞清楚 JWT 和 Session 的区别做权限拦截时顺便看看 Spring Security 的过滤器链是怎么工作的做 Redis 存 token 时顺便了解缓存穿透和过期策略的概念。这些知识在做项目的过程中顺路学一遍面试时就能作为项目经验讲出来而不是背八股文。还有一件事值得花时间把项目跑通一遍完整的业务流程后做一次“我是一名宿管员我现在站在宿舍门口要录入今天的查寝记录”这样的角色代入测试。你会发现很多设计上的不合理之处——比如“查寝记录必须逐间宿舍录入操作特别繁琐”“一个宿舍 8 个人未归名单要点 8 次才能选中”。这些体验上的问题在演示时可能不会被老师注意到但真实使用时会让人崩溃。改进这些细节的过程才是真正的产品思维训练。如果你后续想扩展这个项目方向也有很多接入企业微信消息通知宿管员处理完报修时自动通知学生做宿舍调换审批流涉及两间宿舍的状态一致性把卫生评分和文明宿舍评比结合起来生成学期排名。这些扩展既能增加项目深度也能让你在面试时有更多可以聊的亮点。就我个人经验来说做这种“完整链路”的项目最大的收获不是掌握了 Spring Boot 的某个注解而是建立了一种“从需求到落地的整局观”。你不再是一个只写代码片段的人而是可以独立完成一个产品闭环的开发者。这个能力在任何技术栈上都是通用的。最后送上一句实操建议代码写到一半跑不动的时候别急着在网上搜“为什么报错”先看控制台的最下面一行错误信息再从上往下读堆栈把“异常类型 触发位置”记下来再搜。这个习惯能让你查错的效率提升至少一倍。