企业官网建设流程全解析

1. 为什么寝室管理系统是Java毕设的“稳妥之选”

每年毕业季，我都会收到一堆“学长，毕设选什么题好”的私信。JavaWeb方向的同学尤其多，而且大多数人都卡在同一个问题上：题目既要能过开题答辩，又要能在两三个月内独立完成，还得让答辩老师觉得“这工作量够了”。说实话，寝室管理系统这类选题，就是典型的“看着低调、实则耐用”的题目。

先聊点实在的。寝室管理系统本质上是一个信息管理类Web应用，核心业务就是“宿舍资源分配 + 学生住宿信息维护 + 日常报修/来访/卫生检查流程的管理”。这类系统最大的优势在于：业务场景人人都懂，不需要额外去学什么冷链物流、金融风控的领域知识，需求分析写起来不会卡壳。对大多数JavaWeb方向的本科生来说，这是能把精力集中在“技术实现”而非“业务理解”上的最佳切入点。

再说得直白一点，这类系统一旦做完，你手里能沉淀下来的东西非常完整：前端页面、后端接口、数据库表结构、开发文档、答辩PPT、演示视频，凑齐一套“毕设全家桶”。后续不管是找工作写项目经历，还是准备考研复试的机试，这个项目都能拿出来当作品集。而且基于JavaWeb + MySQL这套组合，一家公司里十个Java后端岗位，有八个用的都是这套技术栈的逻辑，做一遍等于把大学四年学的Web技术串了一遍。

我见过不少同学眼高手低，选题选了个“基于深度学习的校园舆情分析系统”，结果前端不会写、爬虫被反爬、模型训练跑不动，最后两个月全耗在调环境上，连基本的CRUD都没做完。相比之下，寝室管理系统这种题目，技术难度适中、业务边界清晰、工作量可预期，简直是毕业设计里的“六边形战士”。

这篇文章我会从选题调研、功能设计、数据库建模、核心代码实现、环境部署调试这几个维度，把做这个题目的完整路径走一遍。文中涉及的具体表结构、接口设计、排查经验，都是可以直接照抄的作业。如果你正在为毕设发愁，或者手里已经选了这个题但没想清楚怎么做，这篇文章应该能帮你省下至少两周的摸索时间。

2. 功能模块设计与需求拆解：先画清楚边界再动手

2.1 从用户角色出发划分功能边界

寝室管理系统的第一件事，不是写代码，而是搞清楚“谁在用这个系统”。我习惯把这类系统的用户分成三类：学生、宿管员、系统管理员。每个角色看到的功能入口完全不同，这就是RBAC（基于角色的访问控制）最简单的落地场景。

学生端的功能相对轻量：个人信息维护、查看自己的宿舍分配信息、在线提交宿舍报修申请、查看卫生检查结果、登记来访人员信息。注意，这里有一个经常被忽略的细节——学生端不该有“修改宿舍”的权限，只能发起调宿申请，最终审核权一定要攥在管理员手里。

宿管员端的功能就要厚重一些：学生信息管理（入住、退宿、调宿）、宿舍楼栋与房间管理、房间分配与床位管理、卫生检查评分、报修工单处理、来访登记审核、公告发布。这个角色是整个系统的业务核心，大部分后台操作都发生在宿管员这一层。

系统管理员端更多是宏观管控：宿管员账号的创建与权限分配、基础数据字典维护（楼栋编号、宿舍类型、收费标准）、系统操作日志查看、数据统计大屏。很多同学会忽略日志功能，但答辩老师特别喜欢问“你怎么知道是谁在什么时候修改了一条数据”，这时候一个简单的操作日志表就能救你。

2.2 业务流梳理：从入住到退宿的完整闭环

功能列表列出来之后，一定要画业务流程图。寝室管理系统最核心的一条业务链路是“学生入住”，完整流程应该是：学生提交住宿申请（或管理员直接分配）→ 宿管员审核并分配宿舍房间和床位 → 学生确认入住 → 生成入住记录 → 关联水电费账户。

另一条重要链路是“报修流程”：学生提交报修单（填写故障类型、描述、附件照片）→ 宿管员查看并派单 → 维修人员（可以简化成宿管员代操作）处理并填写处理结果 → 学生确认完成 → 生成报修闭环记录。

还有一条容易被遗漏但答辩加分很高的链路是“卫生检查”：宿管员按楼栋和房间录入每周检查评分 → 系统自动汇总评分等级（优秀、合格、不合格）→ 学生端可查看本宿舍历史评分 → 学期末生成文明宿舍评选依据。

这里我强烈建议你在需求文档里把这三条链路用流程图画出来。画图的过程就是逼自己想清楚数据流转的过程，等写代码的时候，你只需要按照图上的箭头去设计接口和状态字段，效率会高非常多。

2.3 非功能性需求：别让性能和安全成为答辩黑点

答辩老师不会只看功能演示，他们一定会问性能和安全。这部分我总结了三个最常被问到的问题，以及对应的处理方法：

第一是并发问题。一个学校的宿舍管理系统，同时在线人数可能就几百人，根本不需要上Redis和消息队列。但如果答辩老师问“如果全校几千人同时登录怎么办”，答案可以是“数据库连接池配置合理 + 页面静态资源走缓存 + 接口层面做参数校验限制重复提交”。用连接池（Druid或HikariCP）是基本操作，建议用HikariCP，性能更好，配置也简洁。

第二是安全问题。学生提交报修时上传的图片必须做文件类型白名单校验和大小限制，防止上传恶意脚本。所有SQL语句必须使用预编译（PreparedStatement），在MyBatis里就是#{}而不是${}拼接，这是防SQL注入的底线。登录密码必须加密存储，别再用明文了，用Spring Security的BCrypt或者至少MD5加盐。

第三是操作体验。答辩现场网络环境不稳定，页面上所有表单提交按钮在点击后要立即置灰并提示“提交中”。这些交互细节虽然不起眼，但会让答辩老师觉得你考虑得很周全。

注意：功能边界一定不能贪多。我看到很多同学喜欢往里加“在线聊天”“失物招领论坛”这些花哨功能，最后把自己累死。要知道毕设的评分核心是“完成度+稳定性+逻辑清晰度”，把基础功能做得扎实比做一堆半成品功能有用得多。

3. 技术栈选型与项目结构：JavaWeb到Spring Boot的演进思考

3.1 技术栈选择的三个层次

如果你去GitHub上搜宿舍管理系统，会看到大量不同年代的版本：有纯JSP + Servlet + JDBC的，有SSH（Struts2 + Spring + Hibernate）的，有SSM（Spring + Spring MVC + MyBatis）的，也有Spring Boot + MyBatis Plus的。很多同学纠结到底用哪套，我的建议很明确：除非学校强制要求使用JSP/Servlet，否则首选Spring Boot + MyBatis Plus + MySQL这套组合。

理由有三点。第一，Spring Boot是目前Java后端开发的事实标准，学了之后找工作直接能用，答辩时老师也会更认可。第二，Spring Boot内嵌Tomcat，不需要单独配置外部服务器，部署和调试都极其方便，对毕设这种时间紧张的项目来说太友好了。第三，MyBatis Plus的代码生成器能在十分钟内生成全套的Controller、Service、Mapper代码，能帮你节省大量的机械劳动。

前端的话，通常有两个选择：服务端渲染的JSP/Thymeleaf，或者前后端分离的Vue + Axios。我的建议是：如果你前端基础薄弱，就用Thymeleaf模板引擎，后端写接口返回ModelAndView，把Java代码和HTML放在一起，虽然不够现代，但胜在简单，答辩也更容易讲清楚。如果你对前端有一定掌握，可以尝试Vue3 + Element Plus做管理后台，Axios调后端接口，这种前后端分离的架构写进简历里会更亮眼。

3.2 项目分层结构与包命名规范

不管选哪套框架，后端代码的分层必须清晰。我个人推荐经典的四层结构：

com.example.dormitory ├── controller // 接收请求，参数校验后调用Service ├── service // 业务逻辑层，事务控制在这里 │ └── impl ├── mapper // 数据访问层，MyBatis的Mapper接口 ├── entity // 实体类，对应数据库表 ├── common // 公共类：统一返回结果、异常处理、工具类 └── config // 配置类：拦截器、文件上传配置等

Controller层只做三件事：接收参数、调用Service、返回结果。Service层负责具体的业务逻辑，并添加@Transactional事务注解，比如办理入住时，既要更新房间的已住人数，还要生成住宿记录，这两个操作必须在一个事务里完成。Entity类要和数据库表字段严格对应，但返回给前端的数据不要直接返回Entity，建议封装一个统一的Result对象。

前端页面的组织也同样需要规矩。管理后台的页面建议统一布局，左侧菜单栏 + 右侧内容区，所有功能页面都嵌入右侧内容区。不要每个页面都写一套完整的HTML骨架，那样后期的样式调整会让你崩溃。用模板引擎的公共片段（Thymeleaf的th:fragment）或者前端组件化（Vue的组件），把侧边栏和顶栏抽出来复用。

3.3 手动搭建还是直接使用代码生成器

这里说点实在的。MyBatis Plus提供的代码生成器可以一次性生成实体类、Mapper接口、Mapper XML、Service接口和实现类。我的建议是：结构性的模板代码用生成器生成，核心业务逻辑必须自己手写。因为答辩时老师大概率会挑几个核心方法问你实现细节，如果连selectStudentByDormId这种查询逻辑都答不上来是自己写的还是生成的，场面会很尴尬。

我一般的手动开发流程是这样的：

1. 设计好数据库表结构，这是最花时间的部分。
2. 用代码生成器生成基础CRUD代码。
3. 根据业务流程图，在Service层逐个实现核心业务方法。
4. 编写Controller层接口，用Postman自测。
5. 最后统一做前端页面。

这套流程走下来，开发效率比逐行手写快一倍以上，而且代码结构极其统一。需要注意的是，生成出来的代码你要能看懂、能讲明白，不要把它当黑盒。

4. 数据库设计：寝室管理系统的核心表结构完整拆解

4.1 整体ER关系与关键设计原则

寝室管理系统的数据库设计是整个项目的地基。我在辅导学生时发现，很多人喜欢把表建得又多又散，学生表、宿舍表一出来就是二三十个字段，到最后关联查询自己都绕晕了。这里我分享一个原则：业务关联大于字段冗余，能通过外键逻辑关联的绝不冗余存储。

核心表我设计了七张：

• sys_user：用户表，涵盖学生、宿管员、管理员三类角色，通过user_type字段区分。
• student：学生信息表，与sys_user一对一关联。
• dormitory：宿舍楼栋表，记录楼栋名称、编号、管理员ID。
• dorm_room：宿舍房间表，记录所属楼栋、房间号、床位数、已住人数、当前状态（空闲/满员/维修中）。
• bed：床位表，每个房间有若干床位，与房间表多对一关联。
• check_in：入住记录表，记录学生入住的历史记录、入住时间、退宿时间。
• repair：报修表，记录报修内容、状态、报修人、处理人、处理结果。

再加上一些辅助表：dorm_hygiene（卫生检查表）、visitor_log（来访登记表）、notice（公告表）、operation_log（操作日志表）。核心就是上面七张，其他都是业务扩展。

为什么要有单独的学生表和用户表分开？因为用户表存的是登录凭证和角色信息，属于“账号体系”；学生表存的是学号、姓名、学院、专业、班级、联系电话这些个人档案，属于“业务数据”。两者分开，一方面避免账号表字段过于臃肿，另一方面也为以后扩展“教职工宿舍管理”留下余地，新加一个teacher表关联sys_user即可，不需要动账号体系。

4.2 关键表结构DDL参考

学生信息表设计时，学号一定要设置唯一索引，这是学生身份的唯一标识，同时也是登录账号（理论上用户名默认就是学号）。

CREATE TABLE `student` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键ID', `user_id` int NOT NULL COMMENT '关联sys_user表的ID', `student_no` varchar(20) NOT NULL COMMENT '学号', `name` varchar(30) NOT NULL COMMENT '姓名', `gender` tinyint NOT NULL COMMENT '性别 0男 1女', `college` varchar(50) DEFAULT NULL COMMENT '学院', `major` varchar(50) DEFAULT NULL COMMENT '专业', `class_name` varchar(50) DEFAULT NULL COMMENT '班级', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `id_card` varchar(20) DEFAULT NULL COMMENT '身份证号，脱敏展示', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_student_no` (`student_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';

宿舍房间表的关联设计要注意，房间属于楼栋，但房间状态是独立维护的。我经常跟学生强调一个点：床位数和已住人数不能靠“数床位表记录”来算，必须在房间表里冗余一个字段。为什么？因为分区、统计、展示时，如果每次都SELECT COUNT(*) FROM bed WHERE room_id=xxx，在数据量大时性能会很差，而且查询逻辑会分散到多处，容易出错。用total_beds和occupied_beds两个字段，每次办理入住时增加占用数，退宿时减少，这个逻辑虽然要仔细维护，但在系统层面远比实时统计可靠。

CREATE TABLE `dorm_room` ( `id` int NOT NULL AUTO_INCREMENT, `dormitory_id` int NOT NULL COMMENT '所属楼栋ID', `room_no` varchar(10) NOT NULL COMMENT '房间号，如501', `floor` int DEFAULT NULL COMMENT '所在楼层', `room_type` varchar(20) DEFAULT NULL COMMENT '类型：四人间/六人间', `total_beds` int NOT NULL COMMENT '总床位数', `occupied_beds` int DEFAULT '0' COMMENT '已住人数', `status` tinyint DEFAULT '0' COMMENT '状态 0空闲 1部分入住 2已满 3维修中', `acreage` decimal(6,2) DEFAULT NULL COMMENT '房间面积', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_dormitory_id` (`dormitory_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='宿舍房间表';

入住记录表是核心业务表，它记录了“谁在什么时间住进了哪个床位”，同时也是学期末统计空床位的依据。这个表务必加上status字段标识当前记录是否有效（1表示在住，0表示已退宿）。查询“当前在住人数”只需一条WHERE status=1的语句。

4.3 关于MySQL的配置要点

现在MySQL官方推荐的是8.x版本，但网上大量教程还停留在5.7。如果你本地装了8.x，有两点需要额外注意。

第一是时区问题。MySQL 8.x默认时区是UTC，如果你在连接串里不指定serverTimezone=Asia/Shanghai，查出来的时间和本地时间能差八个小时。常见的连接串写法如下：

jdbc:mysql://localhost:3306/dormitory?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true

这里面useSSL=false是为了避免本地测试时的SSL握手报错，allowPublicKeyRetrieval=true是针对8.x版本使用caching_sha2_password认证插件时的一个必要参数，不加的话可能会出现“Public Key Retrieval is not allowed”的报错。

第二是Navicat连接报错问题。新手最常见的错误是error 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'（这是Linux环境）或Windows下连接不上3306端口。绝大多数原因是MySQL服务没有启动。Windows下按Win + R输services.msc，找到MySQL服务启动它就行；Linux下用systemctl status mysqld查状态。千万不要一上来就重装，浪费大量时间。

5. 核心代码实现：入住事务、报表统计与权限控制实战

5.1 办理入住：一个必须加事务的完整流程

办理入住是整个系统最典型的业务方法。我在让学生写这个方法时，要求必须包含以下八个步骤：

1. 校验学生是否存在以及是否已在住（防止一学生占两床位）。
2. 校验目标房间是否存在，状态是否为可入住。
3. 校验房间当前还有空床位。
4. 分配一个空床位（优先分配编号较小的床位）。
5. 更新房间的已住人数和状态。
6. 生成入住记录。
7. 更新学生的宿舍关联信息（冗余字段）。
8. 记录操作日志。

这几步任何一步失败，整个操作都要回滚，所以Service方法上必须加@Transactional(rollbackFor = Exception.class)。不设置rollbackFor的话，Spring默认只在运行时异常时回滚，检查异常不会触发回滚，这就是很多同学“数据写到一半”的元凶。

核心逻辑参考如下：

@Override @Transactional(rollbackFor = Exception.class) public Result checkIn(CheckInRequest request) { // 1. 校验学生 Student student = studentMapper.selectByStudentNo(request.getStudentNo()); if (student == null) { return Result.error("学生不存在"); } // 校验是否已入住 LambdaQueryWrapper<CheckIn> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(CheckIn::getStudentId, student.getId()) .eq(CheckIn::getStatus, 1); if (checkInMapper.selectCount(wrapper) > 0) { return Result.error("该学生当前已在住，请先办理退宿"); } // 2. 校验房间 DormRoom room = dormRoomMapper.selectById(request.getRoomId()); if (room == null) { return Result.error("房间不存在"); } if (room.getStatus() == 2) { return Result.error("房间已满"); } if (room.getOccupiedBeds() >= room.getTotalBeds()) { return Result.error("房间无空余床位"); } // 3. 分配床位：查询该房间下仍未分配的床位 LambdaQueryWrapper<Bed> bedWrapper = new LambdaQueryWrapper<>(); bedWrapper.eq(Bed::getRoomId, room.getId()) .eq(Bed::getStatus, 0) .orderByAsc(Bed::getBedNo) .last("limit 1"); Bed bed = bedMapper.selectOne(bedWrapper); if (bed == null) { return Result.error("床位分配异常"); } // 4. 更新床位状态 bed.setStatus(1); bed.setStudentId(student.getId()); bedMapper.updateById(bed); // 5. 更新房间已住人数 room.setOccupiedBeds(room.getOccupiedBeds() + 1); if (room.getOccupiedBeds() >= room.getTotalBeds()) { room.setStatus(2); } else { room.setStatus(1); } dormRoomMapper.updateById(room); // 6. 生成入住记录 CheckIn checkIn = new CheckIn(); checkIn.setStudentId(student.getId()); checkIn.setRoomId(room.getId()); checkIn.setBedId(bed.getId()); checkIn.setStatus(1); checkInMapper.insert(checkIn); // 7. 更新学生房间关联 student.setRoomId(room.getId()); studentMapper.updateById(student); // 8. 日志 operationLogService.record(currentUserId(), "办理入住", "学生" + student.getName() + "入住" + room.getRoomNo()); return Result.success("入住办理成功"); }

这就是一个能拿得出手的核心业务方法。每一步都有清晰的注释，状态流转严谨，异常路径都有兜底。答辩时老师让你说“讲一下你最核心的业务代码”，你指着这一段讲十分钟都行。

5.2 报修流程的状态机设计

报修单的状态流转是一个典型的状态机：待处理 → 处理中 → 已完成，另外还需要一个已关闭或用户取消的终态。我在表设计里给repair表加了一个status字段：

0 -- 待处理 1 -- 处理中（宿管员已接单） 2 -- 已完成 3 -- 已关闭（学生取消/超时未处理自动关闭）

每次状态变更时，在Service层做状态校验。比如学生取消报修只能在待处理状态下进行，宿管员接单后不能直接关闭，必须先标记完成。这些校验逻辑看似琐碎，但正是体现业务严密性的地方。很多毕设被老师批评“逻辑混乱”，往往就是这种状态分支没有处理好。

报修时还有一个小细节：如果学生上传了报修现场的照片，后端需要一个统一的文件上传接口。文件存储路径不要存绝对路径，建议用虚拟路径映射。Spring Boot里配置：

spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB

然后写一个FileController，将上传文件保存到本地磁盘，同时返回文件的访问URL存入数据库。部署时把上传目录配置在application.yml里，用@Value注入，别写死在代码里。

5.3 统计报表的SQL编写思路

答辩时有一个高频要求是“展示一个统计功能”。寝室管理系统里最好做的统计就是“各楼栋入住率”，展示方式可以是柱状图或者饼图。SQL其实很简单：

SELECT d.name AS dormitory_name, COUNT(r.id) AS total_rooms, SUM(CASE WHEN r.occupied_beds = 0 THEN 1 ELSE 0 END) AS empty_rooms, ROUND(SUM(r.occupied_beds) * 1.0 / SUM(r.total_beds) * 100, 2) AS occupancy_rate FROM dormitory d LEFT JOIN dorm_room r ON d.id = r.dormitory_id GROUP BY d.id, d.name;

如果你选了前后端分离方案，前端可以用ECharts拉取这个统计接口，动态构建柱状图。这个功能加进答辩PPT里非常加分，它同时展示了你的SQL功底和前端可视化能力。注意SQL的CASE WHEN和ROUND用法要熟练，答辩时被问到概率极高。

5.4 登录与权限控制的实现方案

权限控制是每个管理系统都必须回答的问题。我推荐在Spring Boot项目里集成Spring Security + JWT，或者退一步使用拦截器 + Session。如果你对Spring Security不熟，用拦截器足够了，但方法要规范。

核心思路是：

1. 登录成功后，将用户ID和角色信息存入Session。
2. 写一个LoginInterceptor，在preHandle方法中检查Session是否存在，不存在则重定向到登录页。
3. 再写一个RoleInterceptor（或直接在preHandle里做角色判断），对/admin/**等路径校验管理员角色。
4. 注册拦截器时配置排除列表：登录页、静态资源（CSS、JS、图片）不需要拦截。

密码存储务必使用BCrypt加密，spring-security-crypto依赖中自带BCryptPasswordEncoder，使用方式：

// 注册时 String encodedPwd = bcrypt.encode(rawPassword); // 登录时 boolean matches = bcrypt.matches(rawPassword, user.getPassword());

这种方法对每个密码自动加盐，即使两个用户密码相同，加密后的密文也不同，数据库泄露了也不容易反推原密码，对比普通MD5强太多。

注意：如果你的系统同时存在学生、宿管员、管理员三类用户，不要给每类用户单独建一个“登录验证接口”。统一走同一个登录接口，比对用户名密码后，根据user_type字段跳转到对应的首页，逻辑才清晰，前后端处理起来也统一。

6. 调试、部署与答辩准备：常见问题排查和实用技巧实录

6.1 IDEA里跑不起来？先检查这三处

我见过太多学生项目打包发给别人后，对方踩的坑比写代码还多。最典型的三个问题：

第一是JDK版本不一致。我用Java 8写的项目，对方机器上装的是JDK 17，跑起来直接报错或者有各种奇怪的警告。解决办法是在pom.xml里明确指定编译器版本：

<properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> </properties>

第二是Maven依赖下载失败。国内网络环境下，Maven中央仓库经常拉取超时。解决方法是在~/.m2/settings.xml里配置阿里云镜像，这个操作能解决90%的依赖下载问题。

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

第三是数据库初始化脚本没跑。项目里附带了一个dormitory.sql文件，很多同学只在后端配置里改了数据库名，忘了执行初始化。注意：SQL文件不仅要导入成功，还要确认每个表都建出来了，尤其是表之间外键字段的字符集要一致，否则会报Collation mismatch或Cannot add foreign key constraint。

6.2 IDA远程调试与Git版本管理习惯

如果你的项目在本地能跑，部署到别人机器上时出了问题，最让人抓狂的就是看不到日志。这里分享一个实用技巧：在启动命令中加入远程调试参数，让对方机器上运行的项目可以通过端口进行调试。

以Spring Boot内置的Tomcat为例，在启动jar包时加上参数：

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar dormitory.jar

然后在IDEA里配置远程调试：Run -> Edit Configurations -> + -> Remote JVM Debug，填写对方机器的IP和端口5005，就能像本地调试一样断点打在远程代码上。这个技巧在帮同学排障时尤其有效，再也不用靠猜和碰了。

另外，一定要养成每个功能模块完成后就提交一次Git的习惯。我用这个方式保护了自己无数次，有一次代码改坏了想回退，一条git checkout -- .就把所有文件恢复到上一个稳定版本。Git不只是一种工具，它是你熬夜写代码时的保险丝。

6.3 答辩演示与代码讲解的高分技巧

最后说说答辩。很多同学项目做得不错，一上台讲就垮掉。我总结了三个答辩加分点和两个避坑点。

加分点一：演示时先说业务场景，再演示操作。比如“现在我们模拟一个学生提交报修的场景，我使用学生账号登录后，选择宿舍、填写报修内容、提交，然后切换宿管员账号查看这张工单并处理。”这种演示方式能让评委快速理解系统逻辑。

加分点二：主动讲出一个你解决过的坑。比如“项目初期发现数据库连接偶尔超时，后来定位到是连接池配置过小，调整maximum-pool-size参数后稳定了。”这种回答远比背教科书有价值。

加分点三：展示日志和数据库状态。把数据库操作日志表翻出来，指给评委看：“您在界面上点了一个按钮，这里的日志表就新增了一条记录，包含了操作人、时间和细节。”实证大于一切。

避坑点一：不要照读PPT。评委更愿意听你说项目解决的业务问题，而不是看你念技术术语。

避坑点二：不要被问倒就沉默。遇到不知道的问题，大方回答“这部分我按照XXX的思路做了初步处理，后续还可以结合XXX继续优化”，比沉默或者乱编好得多。

6.4 打包为可执行jar包与环境迁移

毕设最终一定要交付一个能独立运行的产物。Spring Boot项目打包很简单：

mvn clean package -DskipTests

打出来的jar包放在target目录下，配合你写的SQL初始化脚本和README，就是你交付物的完整组成。记得在README里写清楚环境要求（JDK版本、MySQL版本、初始账号密码），不然给你评分的老师可能都跑不起来。

小技巧：如果想做“绿色版”交付，你可以把MySQL和jar包打在一起，提供一个启动脚本。但这一般不是必须的，绝大多数老师只需要你现场演示或者观看录屏即可。

7. 写在最后的几点实在话

寝室管理系统做起来不难，但要做好做细、做到能答辩能找工作，还是需要下点功夫的。我个人在实际操作中的体会是，这类信息管理系统的关键在于业务状态的流转，你花一个星期把入住、退宿、调宿、报修、卫生检查这几条链路吃透，后面的编码就只是体力劳动了。

再说一点关于“附带源码、文档、调试、代码讲解”这种服务模式的看法。毕设市场鱼龙混杂，有些人完全不写代码，答辩前买个成品应付验收，这种做法我不评价，但风险你自己知道。我更推荐的模式是：把买来的源码当作学习素材，一行一行读通，然后自己动手把核心模块重构一遍。只有你亲自写过一遍的代码，才可能在答辩现场流利地讲出来，才能经得起评委连续追问。买来的东西不会长在脑子里，重构一遍，它才是你的。

最后分享一个扩展方向：如果你做完基础版之后还有余力，可以考虑加一个“宿舍可视化大屏”页面，把楼栋入住率、男女比例、报修完成率用图表展示出来；或者把系统从单体架构拆出一个简单的统计微服务，模拟企业级微服务开发流程。这些扩展点虽然不会显著改变系统架构，但会让你的毕设在众多雷同项目中多一分亮点。

选题已经落定，环境也配置好了，接下来就是按部就班地开发。别想着一口气写完所有功能，按我今天梳理的模块顺序，先完成登录和用户管理，再做学生住宿核心链路，最后补上报修和统计，每周推进一个板块，答辩稳得很。加油。