企业官网建设流程全解析

做毕设选“Java学生宿舍管理系统”的同学，我接触过太多，十个里面至少有八个是同一个想法：这题目耳熟、老师认可、自己有底。前后带过不少学弟学妹把这类项目从零搭到答辩通过，说实话，它确实是个特别适合拿来当毕业设计的题目，但它也绝不是随便敲敲就能糊弄过去的“课设plus版”。

先把选题讲透。学生宿舍管理系统，本质上是一个典型的“后端管理 + 多角色 + 增删改查 + 业务流程流转”的Web应用。它解决的问题非常接地气：学生入住登记、床位分配、退宿销账、报修跟进、访客登记、公告通知、晚归记录、卫生评分，甚至水电数据统计。正是因为它对应的业务场景足够真实、足够贴近普通人的日常认知，答辩时你不需要花五分钟解释“这个系统到底解决什么问题”，演示一两个页面，评委老师自己就看明白价值了。这也是它长期霸榜计算机类毕设热门选题的根本原因。

这篇文章我会用实际带项目视角，把这套系统的选题逻辑、技术选型、数据库设计、核心功能实现、演示录像录制，以及答辩高频问题全部拆开讲。适合正在做这个题目的同学，也适合第一次完整做Web项目、想找一块“安全牌”起步的初学者。后面所有内容都围绕“Java学生宿舍管理系统该怎么从0到1做扎实”展开。

1. 选题定位与整体设计思路

1.1 宿舍管理到底在管什么：先吃透业务

很多同学拿到题目，第一反应是“这不就是学生信息的增删改查吗”，如果抱着这个理解去做，这个项目大概率只能做一个平淡的管理后台，答辩时讲不出东西，老师问深一点就卡壳。

真实的宿舍管理是一串连续的动作，不是一堆孤立的表。学生入学前，宿管中心要先把楼栋、楼层、房间、床位的数据维护好；学生来了要做入住登记，分配宿舍，确认钥匙；住的过程中会出现灯坏了、水管漏了、门锁不好使这类问题，要报修；室友之间调换宿舍要走换宿申请；学生毕业或退学要办理退宿，检查公共设施，归还钥匙；这中间还穿插着晚归登记、访客来访、卫生检查这些日常管理动作；最后，所有数据汇总到宿管中心，作为宿舍资源规划和学生管理的数据支撑。

把这些业务串起来，你会发现一个完整闭环：入住 → 在住 → 迁出，所有模块都是围绕这条主线展开的。真正能在答辩时讲出内容、能被评为“考虑周全”的系统，一定把这条线做完整，而不是只有一张学生信息表和一个登录框。

我建议你在动手写代码之前，先花一个晚上把业务梳理成三句话：

• 宿舍管理员和系统管理员能对“人、房、床”三种资源做哪些操作；
• 学生在自己的角色里能发起哪些动作（报修、换宿申请、查看公告）；
• 每个动作发生后，哪些数据状态要跟着变化（床位状态、住宿状态、记录流水）。

这三句话想清楚了，后面无论是自己写还是参考别人的源码，你都能立刻看出哪个模块是核心，哪个模块是凑数。

1.2 三种角色与功能矩阵

一个标准的学生宿舍管理系统，我做项目时通常会设计成三个角色：系统管理员、宿舍管理员、学生。角色不是越多越好，三个已经足够把权限体系讲清楚，再多就是给自己挖坑。

系统管理员负责全系统的资源配置：创建和管理宿舍管理员账号、维护楼栋和宿舍信息、发布全校公告、查看整体统计看板。宿舍管理员是系统的核心操作者，每天都用：办理入住、办理退宿、处理报修单、登记访客、记录晚归、做卫生检查。学生端则是最简单的那一侧：查看自己住在哪、提交报修、查看公告、查看室友信息，最多再加一个个人换宿申请。

我整理了一张功能矩阵表，做系统设计的时候直接对照着看就行：

这张表的价值在于，它直接决定了你的表设计和接口设计。比如报修单上必须有“提交人、处理人、状态、更新时间”这些字段；访客登记必须绑定宿舍号和来访时间；晚归记录必须绑定学生和日期。很多同学做的时候想到哪写到哪，最后发现某个页面缺字段、某个流程走不通，根源就是前期没有做这个矩阵。

1.3 技术选型：为什么主力推荐 Java Spring Boot

这个题目最主流、也最稳妥的技术组合是：Spring Boot + MyBatis（或 MyBatis-Plus）+ MySQL + Vue/Element UI。前端如果不想拆工程，也可以用 Thymeleaf 服务端模板，一个人在一个工程里把前后端都写完。两种我都带人做过，给你一个参考结论：如果你对前端不熟，Thymeleaf 方案更快，页面和代码在同一个工程里，部署只有一个jar包；如果你稍微有点 Vue 基础，前后端分离方案演示时更好看，页面交互也更顺滑，但工作量会多出百分之三十左右。

为什么选 Spring Boot，而不是学校课程里教的 JSP + Servlet？核心原因有三条。

第一，Spring Boot 天然适合单体应用，自动配置能力把大量繁琐的 XML 配置省掉了，一个文件就能启动整个项目，对单人或双人完成毕设非常友好。第二，生态成熟到“遇事不决搜一下”的程度，几乎每个报错你都能在技术社区找到同款，不用自己从零踩坑。第三，现在的工程实践和招聘市场已经把 Spring Boot 当作 Java 后端的事实标准，你拿它做毕设，至少在技术选型问题上不会让答辩老师觉得“过时”。

我在选择时也对比过其他方案，给你一张比较表：

另外说一句，如果只是想要“能跑、能演示、能答辩”，MyBatis 已经够了；如果不想在单表增删改查上花太多时间，MyBatis-Plus 的 BaseMapper 能帮你省掉大量重复代码，分页也是内置的，整体效率高很多。我个人的建议是选 MyBatis-Plus，但你在答辩前必须能把它的底层 SQL 原理讲明白，否则老师一句“你这条查询实际执行了什么SQL”就能问住你。

1.4 同题不同栈：Python、小程序、PHP 版本怎么变

标题里提到了这个题目还能做成 Python、PHP、小程序 APP 等版本，这一点也值得展开说。同一个宿舍管理业务，换技术栈的核心不是重写业务，而是换一套“表达方式”。

如果选 Python 版本，常见的是 Flask 或 Django 搭配 MySQL，Django 自带 Admin 后台，做管理端非常省事；学生端可以用简单模板渲染，整体开发速度很快。PHP 版本通常用 ThinkPHP 或 Laravel，胜在部署单简单、环境要求低，适合练手。小程序 APP 版本一般是“保持 Java 后端不变，把学生端换到微信小程序”上，宿舍管理员端仍用 Web 管理后台，这是很聪明的组合，既展示了移动端能力，又不用全盘重写。

C# 方向则是用 ASP.NET Core 做后端，思路和 Spring Boot 几乎一一对应。爬虫大数据和单片机方向其实已经属于另一个题目了，如果强行加进宿舍管理系统，通常是加点“宿舍水电数据采集”之类的模块，但不一定适合大多数学校的毕设要求。

所以我的结论是：如果你确定要做“学生宿舍管理系统”，优先 Java Spring Boot 打底；如果个人对 Python 明显更熟，就用 Python 也能做出同等级的系统。业务是根，技术栈是叶，先把业务理解透彻，换语言只是翻译工作。

2. 数据库设计：系统的地基

2.1 核心表规划

数据库设计是这类管理系统的地基，也是答辩时最容易出彩的地方。一个完整的宿舍管理系统，我通常规划八到十张表。核心业务表包括用户表、学生表、宿舍表、入住记录表；流程类表包括报修单、换宿申请表；辅助类表包括访客登记表、晚归记录表、公告表。

用户表存登录账号、密码、角色，是登录功能的根基。学生表存学号、姓名、性别、班级、联系电话、当前宿舍、住宿状态。宿舍表存楼栋名、房间号、楼层、床位数量、当前状态。这里有个设计细节：楼栋和房间我建议合并建模，用“楼栋名+房间号”作为唯一组合键，而不是单独建一栋楼栋表，因为对毕设来说独立楼栋表几乎没有业务价值，合并后查询“某楼栋有哪些房间”只需要一条 where 语句。

床位要不要单独建表，这是一个常见的分歧点。如果房间固定四人间，有人倾向于在宿舍表里加四个床位字段，这种做法在答辩时会被问倒：你怎么查空床位？怎么扩展六人间？我强烈建议单独建一张床位表，每间宿舍根据床位数量初始化对应行数据，床位状态用状态字段区分“空闲/已住/停用”。这样查询空床位就变成一条很清晰的 SQL，入住和退宿时也只需要更新这一行的状态。

报修单和换宿申请表属于“有状态流转”的表，必须带上状态字段（待处理、处理中、已完成等），这是答辩时的重点加分点。访客登记表、晚归记录表则是纯流水表，只需要记录操作时间和操作人即可。公告表最简单，标题、内容、发布时间、发布人。

2.2 学生、宿舍、入住记录三张核心表的结构

下面给出三张最核心的建表 SQL 参考，你可以直接拿去初始化数据库。第一张是宿舍表：

CREATE TABLE dormitory ( id BIGINT PRIMARY KEY AUTO_INCREMENT, building_name VARCHAR(50) NOT NULL COMMENT '楼栋名', room_no VARCHAR(20) NOT NULL COMMENT '房间号', floor INT DEFAULT 1 COMMENT '楼层', bed_count INT DEFAULT 4 COMMENT '床位数量', status TINYINT DEFAULT 1 COMMENT '1可用 0停用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_building_room (building_name, room_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='宿舍房间表';

注意这里的唯一键 uk_building_room，它能保证“同一栋楼同一个房间”不会重复录入，这是宿舍数据干净的生命线。第二张是学生表：

CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL COMMENT '学号', name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT COMMENT '1男 2女', phone VARCHAR(20) COMMENT '联系电话', class_name VARCHAR(50) COMMENT '班级', dormitory_building VARCHAR(50) COMMENT '楼栋名', dormitory_room VARCHAR(20) COMMENT '房间号', status TINYINT DEFAULT 1 COMMENT '1在住 0已退宿', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_student_no (student_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生表';

我这里直接用楼栋名和房间号字段挂在学生表上，而不用外键关联到宿舍表，是为了避免换宿时牵挂太多。你要在答辩时主动解释这一点：不是不会外键，而是这种业务场景下逻辑关联更灵活。这句话一说出来，老师就不会追着外键问题不放。第三张是入住记录表：

CREATE TABLE check_in ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL COMMENT '学号', student_name VARCHAR(50) NOT NULL COMMENT '姓名', building_name VARCHAR(50) NOT NULL, room_no VARCHAR(20) NOT NULL, bed_no VARCHAR(10) COMMENT '床号', operator_name VARCHAR(50) COMMENT '办理人', check_in_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '入住时间', remark VARCHAR(255) COMMENT '备注' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='入住登记记录表';

入住记录表是流水表，只增不改。这样你查“这个学生历史住过哪几个宿舍”就非常轻松，这也是答辩时一个很实用的小亮点。

2.3 我踩过的数据库设计坑

这些坑是我带人做项目时反复出现的，你必须提前避开。

第一个坑是强外键。有些同学建表时给 dormitory_id 设置了 ON DELETE CASCADE 的外键，结果退宿的时候不小心删了宿舍记录，连学生记录一起没了。毕设系统不需要强制物理外键，逻辑关联完全够用，而且更安全。我在项目中统一不建物理外键，只在代码层面保证关联一致。

第二个坑是床位的增删。如果前期没有独立床位表，后期扩展“加一张床”或者“停用一张床”都会非常痛苦。独立床位表之后，这些操作就变成一行 update 或 insert。

第三个坑是时间字段不统一。有的表用 date，有的表用 datetime，答辩时做一个“本月入住人数”的统计，各种格式转换会让你当场翻车。统一用 datetime，并让建表语句带上 create_time 和 update_time，是成本最低的规范。

第四个坑是测试数据太少。演示时只有三五个学生，页面看起来空荡荡，统计看板也是空的。我建议用脚本生成几百条模拟数据，甚至模拟出十几栋楼、每栋六层、每层二十间房，这样所有统计图表一打开就是满满的数据，画面感立刻不一样。

3. 核心功能实现与实操要点

3.1 环境准备与项目初始化

先说环境版本，这个直接关系到你能否一次跑通。JDK 建议用 1.8 或 17，看你们学校实验室统一要求；Maven 用 3.6 以上；MySQL 用 5.7 或 8.0 都行；IDE 用 IntelliJ IDEA 社区版即可，不花钱。前端如果是独立 Vue 项目，Node 版本建议 16 或 18，太新太旧都可能出现依赖装不上的问题。

新建 Spring Boot 项目时，在 IDEA 里用 Spring Initializr 创建工程，Group 填 com.example，Artifact 填 dormitory-system，依赖勾选 Spring Web、MySQL Driver、MyBatis（或 MyBatis-Plus）、Lombok。然后写 application.yml 配置文件：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/dormitory?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver

这里的 serverTimezone=Asia/Shanghai 必须写，不写的话启动大概率报 Server time zone 异常。这是一道新手坎，几乎每个人都会撞一次。

接下来用 Navicat 或命令行执行建库语句创建数据库，然后把上面那张建表 SQL 依次执行。执行完后再插入一个初始管理员账号，密码务必使用加密后的值。项目能启动、能登录，就算完成了第一里程碑。

3.2 登录、鉴权与密码安全

登录是整个系统的门面，也是答辩老师一定会看的模块。我不建议在这个题目里引入 Spring Security，对毕设来说它配置重、概念多，容易把自己绕晕。更合适的方案是：JWT 做令牌 + 拦截器做登录校验 + 角色注解做权限控制。

思路是：用户登录成功后，后端根据用户 ID 和角色生成一个 JWT 字符串返回给前端；前端把 token 存在 localStorage 里，每次请求在 header 里带上；后端写一个拦截器，对所有 /api/** 请求校验 token 是否存在、是否有效；对于需要特定角色的接口，再用方法级注解或拦截器里的路径判断即可。

登录接口的 Controller 示例可以参考下面这种写法：

@RestController @RequestMapping("/api/auth") public class AuthController { @Autowired private UserService userService; @PostMapping("/login") public Result<Map<String, Object>> login(@RequestBody LoginDTO dto) { User user = userService.findByUsername(dto.getUsername()); if (user == null || !user.getPassword().equals(MD5Util.encrypt(dto.getPassword()))) { return Result.error("用户名或密码错误"); } if (user.getStatus() == 0) { return Result.error("账号已被禁用"); } String token = JwtUtil.generateToken(user.getId(), user.getRole()); Map<String, Object> data = new HashMap<>(); data.put("token", token); data.put("role", user.getRole()); data.put("username", user.getUsername()); return Result.ok(data); } }

这里必须强调一件事：密码绝对不能明文入库，最低要求是用 MD5 加固定盐做一次加密存储。虽然 MD5 已经不算安全，但毕设场景下比明文强太多了。你要是用明文密码，答辩老师翻到数据库表的那一刻，印象分基本清零。

拦截器的核心逻辑简单说就是：从请求头取 token，解析失败就返回 401，成功就把用户信息放进请求上下文，后续业务方法里可以直接拿当前登录人。这样每个接口都不用重复写“判断是否登录”，代码会干净很多。

3.3 入住办理与床位分配：事务怎么用

入住办理是整个系统业务逻辑最重的功能，也是最容易出 bug 的地方。一个完整的入住操作，要完成下面这些步骤：

1. 校验学生是否已经处于“在住”状态，防止重复入住；
2. 按“楼栋 → 楼层 → 房间 → 剩余床位”的方式选出目标床位；
3. 校验该床位状态必须为“空闲”，如果已占用则提示换一个；
4. 更新床位表状态为“已住”；
5. 更新学生表的楼栋、房间、住宿状态为“在住”；
6. 插入一条入住登记流水记录。

这六步必须包在一个事务里，缺一不可。为什么要加事务？如果不加，极端情况下会出现“床位已经被占了但学生记录没写进去”的中间状态，虽然毕设并发量不大，但逻辑正确性必须保证。回答答辩追问时，你能说出“这里我用了事务保证数据一致性”这句话，比长篇大论都有效。

在 Spring Boot 里实现很简单，在 Service 方法上加 @Transactional 注解即可，我习惯把事务加在“入住”“退宿”“换宿”“报修派单”这类涉及多表更新的方法上：

@Transactional(rollbackFor = Exception.class) public Result<?> checkIn(CheckInDTO dto) { Student student = studentMapper.findByNo(dto.getStudentNo()); if (student != null && student.getStatus() == 1) { return Result.error("该学生已处于在住状态，不能重复入住"); } Bed bed = bedMapper.findByBuildingAndRoomAndBedNo(dto.getBuildingName(), dto.getRoomNo(), dto.getBedNo()); if (bed == null || bed.getStatus() != 0) { return Result.error("所选床位不存在或已被占用"); } bedMapper.updateStatus(bed.getId(), 1); studentMapper.updateDormitory(student.getId(), dto.getBuildingName(), dto.getRoomNo(), 1); checkInMapper.insert(new CheckIn(dto.getStudentNo(), dto.getStudentName(), dto.getBuildingName(), dto.getRoomNo(), dto.getBedNo(), currentUser(), new Date(), dto.getRemark())); return Result.ok("入住登记成功"); }

有了事务，中间任何一步抛异常，前面的床位更新和学生更新都会自动回滚，数据不会变脏。

退宿流程是入住的逆向操作：先检查该学生是否在住，然后把床位状态改回“空闲”，把学生状态改为“已退宿”，最后插入一条退宿流水记录。这里同样要加事务，同样要写清楚“操作人”和“操作时间”，它是完整业务闭环的直接证据。

3.4 报修状态流转：最有答辩价值的模块

报修模块是我最建议你认真做的功能，因为它是学生端唯一一个包含“状态流转”的业务，也是答辩时最能展示你思考深度的模块。

完整流程是：学生登录后提交报修单，填写宿舍位置、问题描述、可选的图片；宿舍管理员在后台看到新报修，点击“受理”，把状态从“待处理”变成“处理中”；维修完成后，管理员点“完成”，状态变成“已完成”；学生端可以查看自己报修单的当前状态和历史记录。

状态机的定义尽量简单清晰，我通常只用四个状态：

这个模块的代码量其实不大，核心就是一张报修单表加几个更新状态的接口。但它能讲出三样东西：一是状态流转设计，二是不同角色的操作边界，三是报修单与学生表、宿舍表之间的数据关联。答辩时把这个模块讲清楚，老师基本就能认定你不是在背题目，而是真的做完了业务。

3.5 统计看板与演示画面感

首页统计看板是我在所有项目中必做的一个模块，因为它直接决定了系统演示的第一印象。评委打开系统，第一眼看到的是一个空荡荡的列表页，还是看到几个数据卡片和图表，印象是完全不同的。

统计看板不需要复杂算法，主要统计这些指标：当前在住人数、总空床位数、本月报修数量、今日访客人数、男女宿舍分布、各楼栋住宿率。数据来源都是已有的表，写几条 group by SQL 就能搞定。比如“各楼栋住宿率”，本质就是把宿舍表按楼栋分组，统计房间数和在住人数。

图表的展示可以用 ECharts，简单几行配置就能生成柱状图和饼图，把这个模块做成一个独立页面，演示时放第一个打开。很多同学觉得统计功能“不必要”，我反而觉得它是区分“完成”和“做好”的那条分界线。

4. 常见问题与毕设答辩避坑实录

4.1 开发期高频问题速查表

我把自己带项目时反复出现的问题整理成一张速查表，你按图索骥排查，比对着报错日志猜半天有效得多。

这七条几乎覆盖了毕业设计周期里百分之八十的“跑不起来”问题。遇到别的报错，先看控制台完整堆栈定位到具体行，再去网上搜这段错误文字，比拍脑袋改代码靠谱得多。

4.2 演示录像的录制节奏

标题里说可以领演示录像，而你自己也要交一份演示录像，这里面的门道不少。很多同学录视频就是登录、点几下菜单、关掉，一共三分钟，这种录像勉强及格但拿不到高分。合格演示录像的节奏应该是这样：

开场不超过三十秒，说清楚系统名称、使用技术、系统解决什么问题。然后打开首页统计看板，把数据卡片和图表扫一遍，让观看者先建立整体印象。

之后按角色分三段演示：先用管理员账号演示宿舍信息维护、宿管员账号管理、公告发布；再切换宿舍管理员账号，演示入住登记流程、报修单受理和完成；最后切到学生账号，演示登录后提交报修、查看公告和自己的住宿信息。每做一个操作前先说一句“我现在要做什么”，操作完说一句“页面上的结果说明了什么”，让看的人跟得上逻辑。

录屏工具用 OBS 或者系统自带的录屏都行，重点不在工具，在于口播清楚、鼠标操作不飘移。时长控制在十到十五分钟比较合适，太长别人没有耐心看，太短讲不清楚。录之前把演示数据准备好，别在视频里现填测试数据，一旦录错又得重来。

4.3 答辩高频追问与应对思路

答辩环节老师问的问题有规律可循，我列几个最高频的，每个都给你应对思路。

“为什么选这个题目？”不要回答“因为题目简单”，这么说等于把弱点送到老师嘴边。可以说：宿舍管理覆盖了从入住到退宿的完整业务链，包含多角色权限、状态流转、数据统计等典型功能，适合作为一个综合性的毕业设计来锻炼完整项目能力。

“为什么用 Spring Boot 不用 SSH？”回答要点是：Spring Boot 简化了配置和部署，适合单体项目快速开发；底层依然是 Spring 生态，依赖注入、AOP、事务管理等核心机制都有涉及。记住，不要贬低旧技术，说“它更适合当前项目规模和开发效率”即可。

“你的数据库表之间怎么关联的？”这个问题直接对应第二章内容，你指着自己画的表关系图，把学生表、宿舍表、入住记录表、报修单之间的关系和字段讲清楚，这题就稳了。

“退宿之后床位怎么释放？”回答：退宿操作通过事务做三件事，更新床位状态为空闲、更新学生状态为已退宿、写入退宿流水。如果你做了独立的退宿页面，现场演示一遍，这题完美过关。

“报修状态是怎么流转的？”按状态机的思路回答，然后补一句“每个状态变更都记录了操作人和操作时间，可以追溯整个处理过程”。这句话一说，老师会觉得你考虑到了审计层面的东西。

“数据量大了怎么办？”不用慌，这是考察你的扩展意识，不是真要你去扛百万并发。你可以说：目前关键查询字段都建立了索引，列表查询使用了分页；如果数据量进一步增长，可以引入 Redis 做热点数据缓存，也可以把统计类的查询拆分到独立的聚合表里。这个回答足够让老师认可你。

4.4 拿到参考源码后的正确打开方式

现在很多标题会附带“免费领源码”字样的资源，能节省你大量起步时间，但用不好也有风险。我见过太多同学拿到源码改个名字就提交，结果答辩时老师问一个字段含义他都答不上来，当场被认定为“非独立完成”。

正确打开方式是四步走。第一步，先完整跑通项目，确认数据库版本、中间件版本和你本机一致，注意看初始化脚本里有哪些初始账号；第二步，逐模块跑一遍，把每个操作和数据库里的表变化对应起来，至少做到“这个按钮点了以后，哪些表发生了什么变化”心里有数；第三步，挑一个模块深入读代码，比如报修模块，能画出它的接口调用链和状态变化图；第四步，至少亲手改一个功能，比如新增一个“水电费录入”页面，或者给公告模块加上按日期筛选。

改一个功能的意义非常大：第一，你有了真正属于自己的代码；第二，你在改的过程中必然要理解原有代码的路由、Service、Mapper 是怎么组织的；第三，答辩时你可以主动说“这部分是我自己扩展的”，这比回答任何标准问题都加分。直接照搬源码，等于把答辩的生死交到了老师的追问深度上，赌不起。

最后再分享一个我自己的经验。每年答辩我都会和学生说，做这类管理系统，最忌讳只追求“功能多”，最该追求“闭环完整”。你哪怕只做入住、退宿、报修、公告四个核心模块，只要每个模块都能从发起到结束走通，并且数据状态前后一致，就已经是一个合格的毕业设计了。反而是贪多嚼不烂、到处是半成品功能的系统，一看就知道没有真正做完。

如果你时间还算充裕，在基础模块全部完成后，强烈建议补一个“换宿申请审批”功能。很多同题项目都没做完整这个业务，它天然包含申请、初审、审批、床位变更、记录流水这一整条链路，是同类毕设里最容易拉开差距、也最容易成为答辩亮点的模块。希望这篇拆解能让你少走一些弯路，把系统做扎实，也顺利过答辩。