简介：基于Java的学生宿舍管理系统是一套面向毕业设计、课程实训及Java Web初学者的完整项目源码。系统覆盖管理员、宿管、学生三类角色，支持学生、楼宇、宿舍、入住、宿管和管理员等信息的增删改查，并提供表格导入导出；后台采用SpringBoot框架配合MySQL数据库，前端基于Bootstrap搭建，整体结构清晰、模块划分合理，可完整了解前后端交互与权限管理思路，三个角色的登录账号也便于理解用户认证与数据表设计。压缩包共661个文件，以JavaScript、CSS、Java类、XML和HTML页面为主，同时包含SQL脚本、演示视频、说明文档及依赖配置等，大小约72.37MB。内置MySQL5和MySQL8两套适配工程及数据库脚本，可明显降低环境配置成本，解压后即可按文档部署体验。目前已有467人学习，适合需要快速完成宿舍管理课题、毕业设计或想掌握SpringBoot与MySQL开发流程的读者。

1. 基于Java的学生宿舍管理系统：一个能跑通全流程的毕设源码

每年毕业设计季节，宿舍管理系统这类Java课题总被反复点单。这个基于Java的学生宿舍管理系统，不是只有登录页的壳子，而是把学生信息维护、宿舍分配、入住登记、报修处理、来访登记串成一条完整业务链的源码包，拿它当毕业设计底子，能在短时间内补齐一个管理系统该有的骨架：管理员、宿管、学生三类角色，独立的权限入口，以及宿舍分配这种带业务规则的操作。适合三类人：正在找java课程设计案例源码的在校生、需要快速搭一个管理系统原型的开发者、想把Java基础落到实际项目里的初学者。它解决的痛点是，很多人下载源码后卡在“导不进、跑不起来、答辩说不清”，所以这篇笔记的重点也放在这三个环节上。

2. 技术选型与数据库设计：先看pom和建表SQL再动手

拿到任何一个Java毕业设计源码，我一般不会先去点启动按钮，而是先看三个文件：pom.xml、application.yml、数据库脚本。这三个文件能告诉你这套系统的技术栈、运行环境和你需要准备的工具版本。许多下载源码的人第一个坑就踩在这里：IDE 版本太新或者太旧，JDK 对不上，MySQL 版本和驱动不兼容，最后启动报错还以为是源码有问题。

2.1 拿到源码先看三样东西：pom.xml、application.yml、db目录

pom.xml是整个项目的依赖清单。这套宿舍管理系统常见的组合是 Spring Boot + MyBatis + MySQL + Lombok，辅助依赖还有 Druid 连接池。Spring Boot 的版本很关键，如果是 2.x 系列，JDK 用 8 或者 11 都能跑；如果是 3.x，JDK 必须 17 以上。很多人在启动时报出UnsupportedClassVersionError或者Invalid source release，多半就是 JDK 版本没对齐。我通常先用mvn -version确认本地 Maven 和 JDK 版本，再把 pom.xml 里的parent版本号扫一眼，两分钟就能判断兼容性。

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent>

这段配置定义了 Spring Boot 的基线版本，2.7.18 是 2.x 系列的收尾版本，稳定且依赖好拉。如果你本地 JDK 是 1.8，看到这个版本号就可以放心继续。如果是 3.x 版本，就意味着javax包要换成jakarta，代码里的import javax.servlet.*全部会报红，这也是一个很典型的版本切换观察点。

application.yml是运行配置的集中地，里面最需要关注的是数据源配置。很多源码里的数据库密码是作者本机的，比如123456或者root，你拿过来直接跑必然报错。看到spring.datasource这一段，先改成自己 MySQL 的账号密码，同时确认数据库名是否存在。

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/dormitory?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456

这里最容易被忽略的是serverTimezone=Asia/Shanghai。如果安装 MySQL 时用的是默认时区，驱动版本又是 8.x，不配时区参数启动时会报The server time zone value的异常。characterEncoding=utf8和useUnicode=true则是为了保证写入数据库的中文不乱码。这套宿舍管理系统里包含学生姓名、学院、报修描述等大量中文字段，字符集没对齐，后面查数据时看到???会非常头疼。

db 目录或 sql 目录里是建表脚本，通常叫dormitory.sql或init.sql。这一步能告诉你数据库名、表前缀、账号密码等信息。脚本里的CREATE DATABASE语句直接决定了你application.yml里url后面跟的库名是dormitory还是其他名字，两处不一致就等着连接失败。

2.2 数据库设计：六张表如何撑起一块宿舍业务

宿舍管理系统的业务边界比仓库管理系统、图书管理系统更清晰：核心是人与床位的关系。围绕这个关系，常见的设计是六到七张表。我把最能代表这套源码业务逻辑的表结构拆出来，你会发现它没有做得很复杂，但足够覆盖一个毕业设计的全部功能点。

CREATE TABLE `t_user` ( `id` int NOT NULL AUTO_INCREMENT, `username` varchar(32) NOT NULL COMMENT '登录账号', `password` varchar(64) NOT NULL COMMENT '密码', `role` tinyint NOT NULL DEFAULT '2' COMMENT '角色 0管理员 1宿管 2学生', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='登录用户表'; CREATE TABLE `t_student` ( `id` int NOT NULL AUTO_INCREMENT, `student_no` varchar(16) NOT NULL COMMENT '学号', `name` varchar(32) NOT NULL COMMENT '姓名', `gender` tinyint DEFAULT '1' COMMENT '性别 1男 0女', `college` varchar(64) DEFAULT '' COMMENT '学院', `phone` varchar(16) DEFAULT '' COMMENT '联系电话', PRIMARY KEY (`id`), UNIQUE KEY `uk_student_no` (`student_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';

登录用户表和学生信息表分开设计，是一个很值得在答辩时提的点。t_user只负责认证和角色控制，t_student负责业务信息，二者通过学号或用户ID对应。这样设计的好处是，如果以后要扩展教师端或维修工端，不需要改动学生信息表的结构，只要在t_user里增加角色，再新增对应角色资料表就行。这就是数据库设计上的低耦合思路，也是面试里常问的“怎么保证扩展性”的一个朴素案例。

宿舍相关表通常还有t_building（楼栋表）和t_dormitory（房间表），房间表里会冗余一个字段叫capacity（容量）和occupied（已住人数）。这个冗余字段非常重要，后面宿舍分配时判断“是否已满”靠的就是这两列的比对。如果只靠统计入住记录来计算人数，数据库压力大，SQL 也写得复杂。

CREATE TABLE `t_dormitory` ( `id` int NOT NULL AUTO_INCREMENT, `building_id` int NOT NULL COMMENT '所属楼栋ID', `room_no` varchar(16) NOT NULL COMMENT '房间号', `capacity` int NOT NULL DEFAULT '4' COMMENT '容量', `occupied` int NOT NULL DEFAULT '0' COMMENT '已住人数', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='宿舍房间表';

注意occupied是冗余列，它不在设计范式里，而是通过业务操作维护的。比如分配成功后，对这个房间执行occupied + 1；退宿时执行occupied - 1。这种“以空间换查询效率”的做法在很多管理系统里都存在，答辩时如果老师问“为什么要有 occupied 字段”，回答“避免每次查空余床位都对入住记录表做 count 统计，提高列表查询速度”就能明显加分。

再往下是t_checkin（入住记录表）和t_repair（报修表）。入住记录表在这里承担的是一个非常重要的角色：它不仅记录“谁住在哪里”，还记录了入住时间、退宿时间、学期等历史信息。因为学生有毕业、换寝的场景，同一张床在不同时期属于不同学生，没有这张历史表，宿舍的流转记录根本没法追溯。报修表则相对简单，通常是报修人、宿舍房间、故障描述、处理状态这几个字段，状态用0待处理 1处理中 2已完成表达。

2.3 三层拆分：Controller、Service、Mapper各管什么

Java 管理系统的经典分层在宿舍系统里体现得非常标准。Controller 层只做一件事：接收请求、调用 Service、把结果封装返回。它不应该写任何业务判断，哪怕是“宿舍是否存在”这种简单逻辑，也必须放到 Service 里。很多人写代码图省事，直接在 Controller 里查库，短期能跑，但后续接口多了，同一个查询逻辑在多个入口重复出现，改一处漏一处，这属于典型的后期翻车点。

Service 层是业务规则的容器。拿宿舍分配这个操作来说，Service 里至少要处理四个判断：宿舍是否存在、宿舍是否已满、学生是否存在、学生是否已经入住过。这四个判断的顺序也有讲究，先查宿舍再查学生，因为查宿舍时如果不存在，直接抛业务异常，可以省掉后面那个无关的查询。这就是事务方法里“先校验后写库”的基本习惯。

Mapper 层只负责 SQL 和结果映射。MyBatis 的 Mapper 有两种写法：注解写 SQL 或者 XML 写 SQL。毕业设计源码里最常见的还是 XML 方式，因为复杂查询容易调整格式，也方便直接拷出来放到数据库客户端里调试。XML 文件里的<resultMap>映射要留意，数据库的student_no字段和 Java 的studentNo属性如果不做映射，查询结果里这个字段就一直是 null。application.yml里配置的map-underscore-to-camel-case: true能自动完成下划线到驼峰的转换，但前提是 Mapper 查询返回的列名和下划线命名一致。

<select id="selectDormitoryAvailable" resultType="com.dormitory.entity.Dormitory"> SELECT id, room_no, capacity, occupied FROM t_dormitory WHERE building_id = #{buildingId} AND occupied < capacity AND gender = #{gender} ORDER BY room_no </select>

occupied < capacity直接表达“有空位”，gender = #{gender}则保证了男女寝室的隔离。这个 SQL 写在 XML 文件里比写在注解里更容易调试，因为#{buildingId}这类占位符可以直接替换成具体数值，复制到 Navicat 里验证结果。如果你发现某个查询在网页上返回空列表，第一件事就是把 XML 里的整条 SQL 拷到数据库里跑一遍，看是不是字段名拼写或表名前缀问题。

3. 从SQL到启动：把源码跑起来的完整步骤与参数说明

第 2 章弄清楚结构后，就到了动手阶段。这一章的步骤顺序我踩过很多次坑才固定下来：先建库导数据，再改配置，最后启动项目。顺序不能乱，因为启动项目时如果数据库还没建好，Spring Boot 在初始化数据源阶段就失败了，报错信息还会把真正的问题掩盖掉。

3.1 初始化数据库：导入脚本并核对字符集

打开 Navicat 或者命令行，先创建一个空数据库，名字必须是application.yml里url中写的那个，比如dormitory。然后导入项目 sql 目录下的脚本。命令行导入时注意文件路径不能带空格，Windows 下如果路径里有中文也容易出问题。

mysql -u root -p -e "CREATE DATABASE dormitory DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" mysql -u root -p dormitory < dormitory.sql

第一行命令指定了数据库的默认字符集是utf8mb4，比utf8更推荐，因为utf8mb4覆盖了四字节的 emoji 字符，而且和 MySQL 8.x 的默认行为一致。第二行导入表结构和初始数据。导入完成后，建议执行SHOW TABLES;确认表数量，再执行SELECT * FROM t_user;看一眼初始账号是否存在，如果这张表是空的，登录页将无法验证账号，后面所有功能都进不去。

如果导入时报Unknown database，说明第一行命令执行失败，需要检查 MySQL 服务是否启动；如果在导入过程中报Data too long，多半是初始数据里的字符集和表的字符集不一致，删掉重建，并确认 CREATE DATABASE 时带了utf8mb4。

3.2 修改配置：数据源、端口、上传路径三个必改项

打开application.yml，重点修改三处。第一处是数据源，改成自己的 MySQL 账号密码，注意密码如果是纯数字，也要按字符串写法处理，不需要加引号，但如果有特殊字符比如@，必须用单引号包起来。第二处是服务端口，默认 8080，如果本机已被占用，改成 8081 或 9090。

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/dormitory?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 10MB

第三处是文件上传大小限制。宿舍管理系统虽然不太涉及大文件，但很多毕设会把“上传学生头像”作为加分功能，spring.servlet.multipart.max-file-size默认只有 1MB，如果图片稍微大一点就会报MaxUploadSizeExceededException。我把这个值设成 10MB，同时把max-request-size也调大，因为一次请求可能同时上传多张图片，单文件大小限制和请求总大小限制是两个不同的配置。

修改配置后，还要检查一个比较容易忽略的地方：如果项目里用了file.upload-path这种自定义配置，通常会在application.yml底部，值是类似D:/upload/的绝对路径。这个目录必须真实存在，否则上传功能的代码在创建文件时会抛FileNotFoundException。

3.3 启动项目：Maven命令和Spring Boot入口类

在 IDE 里启动之前，先用命令行验证依赖能否正常拉取。在项目根目录下执行：

mvn clean package -DskipTests

mvn clean清理旧的编译产物，package把项目打成可运行的 jar 包，-DskipTests跳过测试类。这一步能提前暴露 Maven 依赖缺失、编译失败的问题，比直接在 IDE 里点启动更可控。如果项目是多人合作或者从网盘下载的，.m2本地仓库里可能缺依赖，命令行里看到Could not resolve dependencies时，需要检查网络环境，或者把 Maven 仓库切换到国内镜像。

编译成功后，在 IDE 里找到启动类，名字一般是DormitoryApplication.java，它上面有@SpringBootApplication注解。右键运行，看到类似下面的日志就算启动成功：

Tomcat started on port(s): 8080 (http) with context path '' Started DormitoryApplication in 8.129 seconds

看到Started DormitoryApplication这行日志，说明应用上下文已经加载完成，数据源可用，Mapper 没有报映射错误。如果启动一半报APPLICATION FAILED TO START，并列出一串Description:和Action:，那就是某个 Bean 初始化失败。最常见的两个原因：数据源连接不上，或者某个 Mapper 的 XML 文件路径配错。这两种错误都不需要立刻改代码，优先检查配置项。

3.4 冒烟验证：从登录到分宿舍的完整链路

项目启动后，打开浏览器访问登录页。初始账号通常在t_user表里，角色为管理员。登录流程看着简单，但它能验证的不只是账号密码，还有 Spring Session、拦截器、首页跳转逻辑是否正常。如果登录后跳转到了空页面，先看浏览器控制台是不是 404，再查 Controller 里@RequestMapping的路径和前端提交的表单地址是否一致。

登录只是第一步。完整的冒烟测试要覆盖：创建一个新楼栋、往楼栋里添加宿舍、录入学生信息、给学生分配宿舍。每一步都对应一张表的写入操作，如果前面建的表结构有字段缺失，走到这里就会暴露。比如录入学生时报字段 'college' 不存在，说明表结构和代码实体没对齐，这时去数据库执行DESC t_student;对比实体类字段即可。

整个链路走通后，再测一遍异常场景：给已满的宿舍分配学生，看系统是否提示“房间已满”。这一步非常关键，因为很多源码这里其实是空的，没做任何判断，硬生生就能把学生塞进超员房间。发现这种情况，就要在第 4 章的代码层面去补事务和校验逻辑。

4. 答辩与Java基础：面向对象、事务一致性和常见追问

源码跑通只是起步，毕业设计答辩和找工作面试考察的是你是否真正理解这套代码。宿舍管理系统看着简单，但它身上浓缩了不少 Java 基础问题。这一章我按答辩老师最常问的顺序，把源码里能拿出来讲的东西拆成三个部分。

4.1 面向对象编程在Java毕设里的四个落点

很多学生答辩时说“我的项目用了面向对象”，但一问“哪里体现了多态”就愣住了。宿舍管理系统里其实有很清晰的落点。

第一个落点是实体类的封装。t_student表对应的Student实体类，所有字段都用private修饰，通过 getter/setter 访问，这就是最基本的数据封装。如果项目里用了 Lombok，类上会有@Data注解，答辩时能直接说出“Lombok 在编译期生成 getter/setter，减少样板代码”就是加分项。

@Data public class Student { private Long id; private String studentNo; private String name; private Integer gender; private String college; private String phone; }

第二个落点是抽象基类。有的源码会设计一个BaseEntity，把id、createTime、updateTime抽出来，其他实体继承它。这就是“抽取共性、避免重复”的继承思想，答辩时顺手就能举出来。

第三个落点是接口与实现的分离。比如报修模块，Controller 里注入的是RepairService接口，实际运行时拿到的是RepairServiceImpl。要说清楚这样做的价值：当你想替换实现逻辑（比如把报修流程改成先自动派单）时，不需要改动 Controller 层，只要重新实现接口并保证方法签名不变。

第四个落点是工具类的静态方法。比如把字符串判空、日期格式化这类通用操作放到StringUtils、DateUtils里，用static方法直接调用，这是对行为复用的理解。四个落点分别对应封装、继承、多态、组合，基本能应对关于面向对象的后续追问。

4.2 数据一致性：从数据库锁到Java事务

答辩高频题之一：两个管理员同时给同一间宿舍分配学生怎么办？这个场景其实就是并发下的数据一致性问题，也是 Java 后端面试里“怎么保证数据一致性”的经典变种。宿舍分配这段代码，我建议你在答辩前把它吃透。

@Transactional(rollbackFor = Exception.class) public boolean assign(Long dormId, Long studentId, String term) { Dormitory dorm = dormitoryMapper.selectByIdForUpdate(dormId); if (dorm == null) { throw new BusinessException("宿舍不存在"); } if (dorm.getOccupied() >= dorm.getCapacity()) { throw new BusinessException("宿舍已满"); } Checkin checkin = new Checkin(); checkin.setStudentId(studentId); checkin.setDormId(dormId); checkin.setTerm(term); checkinMapper.insert(checkin); dormitoryMapper.increaseOccupied(dormId); return true; }

这里的核心是selectByIdForUpdate，它执行的是SELECT ... FOR UPDATE，会对这行记录加排他锁。两个请求同时进入这个方法时，第二个请求会阻塞在查询这一步，直到第一个请求的事务提交后，它才能读到最新的occupied值，然后重新判断是否已满。这就在数据库层面解决了并发分配宿舍的冲突。

要注意@Transactional(rollbackFor = Exception.class)的写法。Spring 默认只在 RuntimeException 上回滚，如果业务异常类继承的是 Exception，不加rollbackFor就不会触发回滚，最后可能出现“入住记录插入成功、occupied 没增加”的脏数据。这是源码里一个特别值得在答辩时主动讲出来的细节，因为很多学生根本不知道rollbackFor有什么用。java怎么保证数据一致性，这个例子就是最标准的回答素材：数据库行锁加事务，保证判断和写入是原子的。

4.3 常见答辩追问与应答框架

老师不会只问业务，还会往 Java 基础方向延伸。我整理了几个高频追问和应对思路。

第一个追问：Integer和int有什么区别？宿舍系统的实体类里gender用的就是Integer，因为数据库字段允许为 null，而基本类型int的默认值是 0，和“未知性别”混淆。这个问题能答清楚，说明你理解包装类型存在的意义。

第二个追问：==和equals的区别？实体类之间比较用equals，基本类型比较用==。如果项目里用 Lombok，@Data会自动生成equals和hashCode，可以顺便说出为什么重写equals必须重写hashCode：保证两个对象相等时哈希值也相等，否则放入 HashSet 或 HashMap 时会出现逻辑错误。

第三个追问：List和Map在宿舍系统里分别用在哪？List用在展示楼栋列表、学生列表这种有序集合；Map常用于统计每个楼栋的入住率，key 是楼栋ID，value 是统计结果。回答时结合项目代码举例，比背概念有说服力得多。

第四个追问：java对象深度拷贝是干什么的？比如用户修改个人资料时，如果直接拿 session 里的对象做修改再存库，可能会污染缓存中的原对象。更稳妥的做法是复制一个临时对象，修改后再传给 Service 层。能主动提出这个点，老师会认为你有生产环境意识。

5. 避坑指南：宿舍管理系统跑不起来的五个典型问题

这个章节是下载源码后最容易翻车的地方。我把这套系统里出现频率最高的五个问题按现象、原因、解决的顺序写出来，每条都是我实测过的记录，按顺序排查能省大半天时间。

5.1 现象：启动报Communications link failure

报错信息末尾通常跟着The last packet sent successfully to the server was 0 milliseconds ago。原因基本是应用连不上 MySQL，要么是 MySQL 服务没启动，要么是端口不对。Windows 上很多人安装了 MySQL 但没注册成系统服务，每次都要手动启动。

解决：先在命令行执行mysql -u root -p，能进说明服务正常。这里要确认连接的端口，application.yml里url如果写的是localhost:3306，而本机 MySQL 跑在 3307，连接必然失败。还有一种情况：MySQL 8.x 默认使用caching_sha2_password认证，老版本驱动不兼容，报错里能看到Unable to load authentication plugin。解决方式是换成com.mysql.cj.jdbc.Driver，并确保 mysql-connector-java 版本在 8.0 以上。

5.2 现象：启动时报端口被占用

Tomcat start failed或者Port 8080 was already in use。原因很直白：本机已经有程序占用了 8080。常见的是之前启动过的残留 Java 进程，或者本机装了其他 Web 服务。

解决：执行netstat -ano | findstr 8080，最后一列是占用进程的 PID，然后用taskkill /PID 进程号 /F强制结束。如果不想动那个进程，直接改application.yml里的端口到 8081 更省事。注意改完端口后，前端页面里的请求地址如果是写死的 8080，那也要同步改，否则页面能打开但所有接口都请求不通。

5.3 现象：Maven 依赖一直下载中或者 jar 包报红

pom.xml里某个依赖一直加载不进去，或者下载到一半卡住。原因大多是默认的 Maven 中央仓库在国外，网络波动下很容易失败。

解决：在settings.xml里配置阿里云镜像。顺便建议把本地仓库.m2路径也确认一下，避免 IDE 内置 Maven 和命令行 Maven 用的是两个不同仓库，导致一边能编译一边报缺包。

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/central</url> </mirror>

配置完镜像后，回到 IDE 执行mvn -U clean compile，-U参数强制更新快照版本。如果之前下载过损坏的半截 jar，建议把.m2/repository里对应目录删掉重新拉。

5.4 现象：页面中文全部是问号

列表页、详情页的中文显示成???，或者往数据库里写入中文后再查出来是乱码。原因通常是三层字符集不一致：数据库表字符集、application.yml的characterEncoding、页面编码。

解决：先查SHOW CREATE TABLE t_student;，如果DEFAULT CHARSET不是utf8mb4，要把整张表转过去：

ALTER TABLE t_student CONVERT TO CHARACTER SET utf8mb4;

然后确认application.yml的 url 里已经带了characterEncoding=utf8，最后检查页面<meta charset="UTF-8">。如果用的是 JSP，还可能在 web.xml 里需要配置编码过滤器。乱码问题只要链路中有一层不一致就会出问题，最好一次性全部核对。

5.5 现象：宿舍已满但学生还是被分配进去了

这个属于逻辑层面最隐蔽的坑。如果源码里分配宿舍的方法没有加事务和行锁，两个管理员同时操作时，后一个请求拿到的是旧数据，判断“未满”后插入入住记录，结果实际人数超过容量。

解决：按第 4 章的代码改造assign方法，用selectByIdForUpdate加行级锁，并确保@Transactional的回滚条件是Exception.class。改完后用两个浏览器窗口同时提交分配请求做压测，观察最终occupied是否超过capacity。这是从“能用”到“能用对”的关键一步，答辩时拿出来讲，含金量很高。

6. 进阶验证：用Postman和日志把源码变成答辩底气

源码跑通以后，我建议你用 Postman 把核心接口完整串一遍，而不是只在网页上点来点去。原因很简单：网页点击是浏览器帮你组装了参数，接口是不是真的正确，你未必知道。用 Postman 直接调接口，能确认每个接口的请求方式、参数格式、返回结构，这也是一张最扎实的答辩底牌。

先做登录。解析页面里的表单请求，拿到登录接口的地址和参数名，一般是username和password。调用成功后，响应体里通常带一个 token 或者把用户信息放入 session。如果是前后端分离的结构，token 会放在响应头里，后续所有请求都要在 Header 里加Authorization。

验证完登录后，按业务顺序依次调：新增楼栋、新增宿舍、录入学生、分配宿舍、查询入住列表、提交报修、处理报修。每成功一个接口就在表格里记一笔：

每个接口的响应时间也值得记录，正常情况下本地调试都在 100ms 以内。如果某个接口超过 500ms，去检查是不是查询语句没走索引，比如t_checkin表的student_id字段有没有建索引，这是 SQL 层面上最容易忽视的细节。

日志是另一个被低估的验证工具。在application.yml里开启 MyBatis 的 SQL 日志，把 Mapper 执行的真实 SQL 打印出来：

logging: level: com.dormitory.mapper: debug

com.dormitory.mapper是 Mapper 接口所在的包名。开启后，控制台会输出每条 SQL 的预编译语句和参数值，比如==> Preparing: select * from t_student where student_no = ?后面跟着==> Parameters: 2021001(String)。它能帮你确认两件事：一是代码里的#{studentNo}是否正确传递了值，二是 MyBatis 的一级缓存是不是导致查询结果没刷新。答辩时如果老师问“你用什么工具定位过问题”，你能把 SQL 日志、Postman 接口测试、断点调试这三样具体说出来，整个项目的可信度就完全不同。

从那以后，我拿到任何一个 Java 毕设源码，都会强制自己走一遍固定的检查序列：pom 看版本、配置看数据源、SQL 按字符集导库、启动看端口、日志看 SQL 参数、最后用 Postman 回归一遍核心链路。这套流程一遍走下来，源码是真的读懂还是只是能跑，边界在哪里、并发场景下会不会炸，心里就有一本明白账了。希望帮到你。

本文还有配套的精品资源，点击获取