Java宿舍管理系统源码解析：Spring Boot+MySQL从环境配置到答辩

简介基于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.xJDK 必须 17 以上。很多人在启动时报出UnsupportedClassVersionError或者Invalid source release多半就是 JDK 版本没对齐。我通常先用mvn -version确认本地 Maven 和 JDK 版本再把 pom.xml 里的parent版本号扫一眼两分钟就能判断兼容性。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.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?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456这里最容易被忽略的是serverTimezoneAsia/Shanghai。如果安装 MySQL 时用的是默认时区驱动版本又是 8.x不配时区参数启动时会报The server time zone value的异常。characterEncodingutf8和useUnicodetrue则是为了保证写入数据库的中文不乱码。这套宿舍管理系统里包含学生姓名、学院、报修描述等大量中文字段字符集没对齐后面查数据时看到???会非常头疼。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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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 idselectDormitoryAvailable resultTypecom.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 /selectoccupied 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?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse 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 -DskipTestsmvn 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基本类型比较用。如果项目里用 LombokData会自动生成equals和hashCode可以顺便说出为什么重写equals必须重写hashCode保证两个对象相等时哈希值也相等否则放入 HashSet 或 HashMap 时会出现逻辑错误。第三个追问List和Map在宿舍系统里分别用在哪List用在展示楼栋列表、学生列表这种有序集合Map常用于统计每个楼栋的入住率key 是楼栋IDvalue 是统计结果。回答时结合项目代码举例比背概念有说服力得多。第四个追问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 idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://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 里已经带了characterEncodingutf8最后检查页面meta charsetUTF-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。验证完登录后按业务顺序依次调新增楼栋、新增宿舍、录入学生、分配宿舍、查询入住列表、提交报修、处理报修。每成功一个接口就在表格里记一笔接口功能请求方式预期结果实际结果管理员登录POST /api/login返回 token通过新增楼栋POST /api/building返回新增ID通过分配宿舍POST /api/checkin/assign返回“分配成功”通过提交报修POST /api/repair/add返回“报修已提交”通过每个接口的响应时间也值得记录正常情况下本地调试都在 100ms 以内。如果某个接口超过 500ms去检查是不是查询语句没走索引比如t_checkin表的student_id字段有没有建索引这是 SQL 层面上最容易忽视的细节。日志是另一个被低估的验证工具。在application.yml里开启 MyBatis 的 SQL 日志把 Mapper 执行的真实 SQL 打印出来logging: level: com.dormitory.mapper: debugcom.dormitory.mapper是 Mapper 接口所在的包名。开启后控制台会输出每条 SQL 的预编译语句和参数值比如 Preparing: select * from t_student where student_no ?后面跟着 Parameters: 2021001(String)。它能帮你确认两件事一是代码里的#{studentNo}是否正确传递了值二是 MyBatis 的一级缓存是不是导致查询结果没刷新。答辩时如果老师问“你用什么工具定位过问题”你能把 SQL 日志、Postman 接口测试、断点调试这三样具体说出来整个项目的可信度就完全不同。从那以后我拿到任何一个 Java 毕设源码都会强制自己走一遍固定的检查序列pom 看版本、配置看数据源、SQL 按字符集导库、启动看端口、日志看 SQL 参数、最后用 Postman 回归一遍核心链路。这套流程一遍走下来源码是真的读懂还是只是能跑边界在哪里、并发场景下会不会炸心里就有一本明白账了。希望帮到你。本文还有配套的精品资源点击获取