企业官网建设流程全解析

做了这么多年Java方向的毕业设计辅导和开发，“springboot智慧教室预定系统”这个题目几乎每隔几个月就会出现一次。说实话，它算是一个被市场反复验证过的经典题目——难度适中、需求清晰、技术栈主流，既能覆盖SpringBoot生态的核心知识点，又不会涉及太复杂的硬件对接，非常适合用来完成一份拿得出手的毕业设计。

这篇文章我想从一个开发过来人的角度，把这个题目从需求分析到落地实现完整拆一遍。不吹概念，只讲实操，包括数据库怎么做、时间段冲突怎么判断、SpringBoot版本怎么选、前端Vue打包后怎么塞进SpringBoot里这些最让人头大的细节，全部记录下来。如果你是正在选这个题目的学生，或者想快速搭建一套能跑的教室预定系统，这篇文章应该能帮你省很多时间。

1. 项目整体设计与技术选型思路

1.1 需求拆解：教室预定系统到底管什么

很多人拿到“智慧教室预定系统”这个题目，第一反应是往“智慧”两个字上靠，想做物联网、人脸识别、门禁联动、教室设备自动化管理。思路没错，但如果这是本科毕业设计，我的强烈建议是——先把基础业务做完做稳，再谈智能化的锦上添花。

从业务本质上看，教室预定系统解决的是一个非常现实的问题：高校教室资源是公共资源，但各个院系、社团、学生组织都有临时使用教室办活动、开组会、上自习的需求。传统方式靠教务处排课表或者教室管理员手写登记，效率低、冲突多、信息不透明。这个系统的核心价值就是让教室预定从线下转为线上，实现信息的实时共享和资源的规范化管理。

核心用户角色至少要有三类：

• 学生：浏览教室空闲情况，提交预定申请，查看和处理自己的预定记录。
• 教师/辅导员：在会议室里通常归类为普通用户，但预定优先级更高，有时也需要审批权限。
• 管理员：维护教室基础信息，审核预定申请，处理冲突和违约，管理用户账号。

核心业务流程也围绕“查询-提交-审批-使用-记录”这条线展开。比如一个学生要预定明晚7点到9点的教室，他需要知道这个时间段哪些教室空闲，空闲的教室什么规格、能坐多少人、有没有多媒体设备，提交申请后要等管理员审批，审批通过后才能使用。使用结束后，这条记录留痕，后续可以统计教室使用率。

这个需求拆解过程非常重要，因为整个系统的表结构设计、接口设计、权限设计全部围绕它来展开。很多同学一上来就写代码，写到一半发现缺表、缺接口、逻辑绕圈，就是因为需求没有拆清楚。

1.2 技术栈选型与架构设计

技术选型上，最稳妥、也是绝大多数毕业设计采用且答辩不翻车的组合是：

这套选型算得上“毕业设计黄金组合”，原因很简单：SpringBoot让人不再需要花大量时间在XML配置上，按约定走就可以快速启动一个Web项目；MyBatis-Plus让单表CRUD几乎不写SQL；Vue这种前端框架配合Element组件库，做管理界面效率非常可观。

关于框架版本的问题我额外说一句。2024年之后SpringBoot 3.x已经是主流，但毕业设计我不建议你主动选3.x。如果你不是自己搭项目而是用现成的脚手架，3.x在部分依赖上（特别是旧版的MyBatis-Plus、某些文件上传组件和数据库驱动）存在兼容风险。很多同学搜资料、查博客时，网上大量解决方案还是针对2.x的，版本太高反而会导致“照着抄都报错”的尴尬局面。先用SpringBoot 2.7.18这个最终维护版本，是最稳的。

1.3 架构分层设计

后台代码规范分层是答辩时老师一定会看的结构。一个标准的SpringBoot项目包结构大概是这样的：

com.example.classroom ├── config // 配置类：跨域、MyBatis-Plus分页、JWT拦截器 ├── controller // 控制层：接收请求，返回JSON ├── service // 业务层：处理核心逻辑 │ └── impl ├── mapper // 持久层接口，继承BaseMapper ├── entity // 实体类，对应数据库表 ├── dto // 数据传输对象，接收前端参数 ├── vo // 视图对象，返回给前端的数据 ├── common // 统一返回结果、异常处理、常量定义 └── utils // JWT工具类、日期时间工具类

这样的分层好处是逻辑清晰、职责单一。Controller层只负责参数接收和结果返回，Service层处理业务规则，Mapper层和数据库打交道，谁都不越界。答辩时老师问“你项目结构怎么设计的”，你可以很坦然地告诉他这是标准的MVC+RESTful风格。

接口设计上，建议整体走RESTful风格。比如：

• POST /api/auth/login登录
• GET /api/classrooms获取教室列表
• GET /api/classrooms/{id}/available?startTime=&endTime=查询空闲情况
• POST /api/reservations提交预定申请
• PUT /api/reservations/{id}/approve管理员审批
• DELETE /api/reservations/{id}取消预定

统一返回格式也很重要。我习惯用Result<T>封装，包含code、message、data三个字段，code为200表示成功，其他为业务错误码或异常码。这样做的好处是前端的axios拦截器可以统一处理错误弹窗，不需要每个接口单独写一次错误处理逻辑。

2. 核心功能模块与数据库建模

2.1 功能模块细化

系统按模块划分，可以拆成6个主要部分：

第一个是用户认证模块。学生、教师、管理员都通过同一个登录入口进入，后端根据账号角色返回不同的权限菜单。注册功能简单一点，默认注册的角色是学生，管理员账号可以通过SQL直接插入或者提供一个默认管理员的初始化接口。

第二个是教室管理模块。管理员维护教室编号、楼栋、楼层、容量、设备信息（投影、音响、空调）、是否可预约等字段。教室列表支持按容量、设备条件筛选。

第三个是教室查询模块。这是用户使用最频繁的模块。用户选择一个日期，再选择开始时间和结束时间，系统展示所有满足时间段要求的空闲教室列表。这个模块最难的点就是空闲判断逻辑，后面我会专门讲。

第四个是预定管理模块。用户提交预定申请后生成一条待审批记录，管理员在待办列表里审核通过或驳回。用户本人的页面展示“我发起的预定”，按状态区分待审批、已通过、已驳回、已取消、已完成。

第五个是个人中心模块。用户可以修改部分个人资料、查看历史预定记录、管理自己的预约（比如取消一场还没开始的活动）。

第六个是数据统计模块，这是答辩加分项。按周或按月统计教室使用率、各教室预定次数Top10、申请通过率等，用ECharts在前端展示柱状图和饼图。

2.2 数据库表结构设计

数据库设计是这类管理系统的地基，表结构设计得不好，后面写业务逻辑会处处别扭。核心表就三张，其他的都是为了辅助这三张表。

第一张表是用户表sys_user：

CREATE TABLE `sys_user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '账号', `password` varchar(255) NOT NULL COMMENT 'BCrypt加密后的密码', `real_name` varchar(50) NOT NULL COMMENT '真实姓名', `role` tinyint NOT NULL DEFAULT 1 COMMENT '角色：1学生 2教师 3管理员', `phone` varchar(20) DEFAULT NULL, `email` varchar(100) DEFAULT NULL, `status` tinyint NOT NULL DEFAULT 1 COMMENT '1正常 0禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码一定要加密存储，不要明文、不要简单MD5，推荐用BCryptPasswordEncoder。教材里正是Spring Security提供的标准加密方案，答辩时老师问密码安全性，完全拿得出手。

第二张表是教室表classroom：

CREATE TABLE `classroom` ( `id` bigint NOT NULL AUTO_INCREMENT, `room_code` varchar(30) NOT NULL COMMENT '教室编号，如A-101', `building` varchar(50) DEFAULT NULL COMMENT '所属楼栋', `floor` int DEFAULT NULL COMMENT '楼层', `capacity` int DEFAULT 0 COMMENT '容量', `has_projector` tinyint DEFAULT 0 COMMENT '是否有投影', `has_computer` tinyint DEFAULT 0 COMMENT '是否有电脑', `has_air_conditioner` tinyint DEFAULT 0 COMMENT '是否有空调', `status` tinyint DEFAULT 1 COMMENT '1可预约 0不可用', `remark` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_room_code` (`room_code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

第三张表也是最核心的一张表——预约记录表reservation：

CREATE TABLE `reservation` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL COMMENT '预约人ID', `classroom_id` bigint NOT NULL COMMENT '教室ID', `reservation_date` date NOT NULL COMMENT '预约日期', `start_time` time NOT NULL COMMENT '开始时间', `end_time` time NOT NULL COMMENT '结束时间', `purpose` varchar(255) DEFAULT NULL COMMENT '使用用途', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待审批 1已通过 2已驳回 3已取消 4已完成', `approve_user_id` bigint DEFAULT NULL COMMENT '审批人ID', `approve_remark` varchar(255) DEFAULT NULL COMMENT '审批意见', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_classroom_date` (`classroom_id`, `reservation_date`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

reservation表在设计上有一个关键考虑——状态字段。我把它设计为整型枚举，而不是字符串。整型在查询和索引上效率更高，配合MyBatis-Plus可以很方便地做状态流转判断。为什么预留“已完成”这个状态？因为在管理员审核通过后、使用时间结束后，系统应该能自动把记录从“已通过”变成“已完成”，这样才能支撑后面的使用率统计。

2.3 查询索引与数据一致性

很多毕设项目不考虑数据库索引，这在数据量小的时候没问题，但答辩时老师问到性能优化就会卡壳。我上面在reservation表里加了两个索引：idx_classroom_date和idx_user_id，分别用于教室时间段查询和用户自己的预约列表查询，这两个正是系统最频繁的查询路径。

数据一致性方面，预定系统的核心约束是“同一间教室同一时间段不能被两个人同时预约”。这个约束要靠两层保障：

第一层是应用层校验，在提交预约时检查冲突记录是否存在，存在则拒绝。第二层是数据库层约束，可以做一个组合唯一索引，但时间范围冲突用唯一索引很难优雅表达（例如A预定了8:00-10:00，B要预定9:00-11:00，这两条记录在数值上并不相同，但业务上冲突了），所以实际中用应用层校验+事务就足够了。

我建议在Service层提交预约的方法上加上@Transactional注解，因为这里涉及查询和插入两步操作，不加事务可能出现并发问题。

3. 关键功能实现与实操代码解析

3.1 时间段冲突检测的实现思路

时间段冲突检测是这个系统最核心、也最容易写错的逻辑。先明确业务规则：用户提交一个预约请求，包含date（日期）、startTime、endTime三个关键参数，系统需要找出在同一个教室下，已经存在“状态为已通过或待审批”的记录中，是否有任何一条与请求的时间段重叠。

这里有个很关键的设计决策：判断冲突时，待审批状态的记录要不要纳入冲突范围？我的选择是纳入。因为如果一条记录还在等审批，但管理员又收到了另一条同教室同时段的请求，从资源分配上看就有重复占用的风险。比较好的做法是：一条教室记录一旦被提交预约且进入待审批阶段，就视为“暂时锁定”，直到审批被驳回才释放。

时间重叠的判断条件可以用SQL表达。两个时间段[s1, e1]和[s2, e2]发生重叠的条件是：s1 < e2 AND s2 < e1。这个判断方式简洁且无遗漏。举几个例子验证一下：

• 现有预约8:00-10:00，新预约10:00-12:00：8 < 12且10 < 10不成立，不重叠，正确（首尾相接是允许的）。
• 现有预约8:00-10:00，新预约9:30-11:00：8 < 11且9.5 < 10成立，重叠，正确。
• 现有预约8:00-10:00，新预约7:00-8:30：8 < 8.5且7 < 10成立，重叠，正确。

3.2 冲突检测的代码实现

在Service层实现冲突检查，核心代码大概这样写：

// ReservationServiceImpl 中新增的冲突检查方法 public void checkConflict(ReservationDTO dto) { LambdaQueryWrapper<Reservation> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Reservation::getClassroomId, dto.getClassroomId()) .eq(Reservation::getReservationDate, dto.getReservationDate()) .in(Reservation::getStatus, Arrays.asList(0, 1)) // 待审批 + 已通过 .apply("start_time < {0} AND end_time > {1}", dto.getEndTime(), dto.getStartTime()); if (this.count(wrapper) > 0) { throw new ServiceException("该教室在此时间段已被预约，请选择其他时间"); } }

这里用了MyBatis-Plus的apply方法拼原生SQL片段，干净利落。很多人会直接在实体类查询后Java代码里循环判断，不是不行，但性能和写法都不如一段SQL优雅。要特别注意的是条件里in状态集合这一步，很多人漏掉状态过滤，导致查询出来的冲突记录里有“已驳回”“已取消”的数据，明明场地空着却提示冲突，用户体验很差。

提交预约的完整流程是这样的：

@Transactional(rollbackFor = Exception.class) public void createReservation(ReservationDTO dto) { // 1. 参数校验：日期不能是过去日期、时间范围合法、教室存在且可预约 validateReservationParams(dto); // 2. 冲突检查 checkConflict(dto); // 3. 构造记录并保存 Reservation reservation = new Reservation(); reservation.setUserId(dto.getUserId()); reservation.setClassroomId(dto.getClassroomId()); reservation.setReservationDate(dto.getReservationDate()); reservation.setStartTime(dto.getStartTime()); reservation.setEndTime(dto.getEndTime()); reservation.setPurpose(dto.getPurpose()); reservation.setStatus(0); // 待审批 this.save(reservation); }

顺便提一个@Transactional回滚的细节：方法内部抛出的异常默认会触发回滚，但是只对RuntimeException和Error生效。如果你在自己的业务异常类上没做特殊配置，要注意它是否继承RuntimeException。我习惯在自定义异常ServiceException里直接继承RuntimeException，省去一堆麻烦。

3.3 前端空间筛选与剩余容量计算

教室查询页面是用户看到的第一屏。前端传过来的是三个参数：日期、开始时间、结束时间。后端要做的是查询所有状态正常且未在该时间冲突的教室列表。

这里有一个潜在的坑：如果数据量小，直接全表查出来在Java内存中过滤是能跑的方案，但数据量大或者答辩现场演示卡顿就尴尬了。正确姿势是用一条SQL完成“排除法”。

思路是：先查出来指定时间段内所有被占用（状态为待审批或已通过）的教室ID集合，然后用排除条件查询所有不在这个集合里的可用教室。SQL层面可以用NOT EXISTS：

SELECT * FROM classroom c WHERE c.status = 1 AND NOT EXISTS ( SELECT 1 FROM reservation r WHERE r.classroom_id = c.id AND r.reservation_date = #{date} AND r.start_time < #{endTime} AND r.end_time > #{startTime} AND r.status IN (0, 1) )

写完这段SQL，我建议你手动跑一遍测试几个时间边界：startTime=endTime、跨天时间、还有深夜时间段的预约。跨天预约（比如10月1日22:00到10月2日2:00）在大多数毕业设计里是不允许的，因为一条记录的date字段只有一个值，跨天会让判断逻辑复杂化。我给出的解决方案是：在参数校验阶段就拦截跨天请求，明确提示用户“预定时间不能跨天”，同时限定可预约时间范围，例如8:00到22:00之间。

3.4 定时任务：状态自动流转的一个小进阶

一个完整的教室预定系统，还应该有一个后台定时任务：把已经过了使用结束时间并且状态为“已通过”的预约记录，批量更新为“已完成”。这样数据统计模块才有数据可用，也避免“活动都结束两天了，状态还显示已通过”的尴尬。

实现方式就是SpringBoot的定时任务，在启动类上加上@EnableScheduling，然后写一个定时任务类：

@Component public class ReservationStatusTask { @Resource private ReservationMapper reservationMapper; // 每分钟执行一次，超过结束时间且状态为已通过的，标记为已完成 @Scheduled(cron = "0 * * * * ?") public void autoCompleteReservations() { LambdaUpdateWrapper<Reservation> wrapper = new LambdaUpdateWrapper<>(); wrapper.eq(Reservation::getStatus, 1) .lt(Reservation::getEndTime, LocalTime.now()) // 这里需要处理跨日的情况，更严格的需要再加日期条件 .set(Reservation::getStatus, 4); reservationMapper.update(null, wrapper); } }

严格来说，这个定时任务还要判断reservation_date等于今天或早于今天的条件，否则会把明天预约的还没开始的记录错误更新为已完成。写的时候多想想边界条件，别让定时任务帮倒忙。

3.5 前端Vue打包放进SpringBoot

这是我在无数个交流群里被问到吐的问题：“前端写完怎么和后端一起部署？”“Vue打包后放哪里？”“为什么我打包放进去访问不了？”

设计方案是：用npm run build把Vue项目打包，产物默认在dist目录下，然后把dist目录下的所有文件复制到SpringBoot项目的src/main/resources/static/目录中。SpringBoot会自动将static目录作为静态资源根目录映射。

要在本地开发时前后端不打架，你需要给Vue项目里的vue.config.js（Vue 2）或vite.config.js（Vue 3）配置一个devServer.proxy，把/api前缀的请求代理到后端的http://localhost:8080，避免开发环境下的跨域问题。

生产环境打包后，前端请求的/api地址会变成相对路径，因为文件本身就在后端服务里了，不再有跨域问题。这里有一个隐藏的小坑：后端接口地址如果写了http://localhost:8080/api/xxx这种绝对路径，打包部署后就会失效。所以前端封装axios时，baseURL应该直接写/api，而不是写带域名的完整地址。

最常遇到的一个问题是刷新404。原因是Vue Router使用History模式时，前端路由是客户端路由，刷新时会向服务器请求对应的路径，而后端没有这个路由映射，就返回404了。解决办法有两个：一是Vue Router改用Hash模式，URL变成/#/xx形式，但这种形式你作为一个开发者看了可能不太舒服；二是在后端写一个WebMvcConfigurer配置类，把不存在的路径转发到index.html。作为毕设项目，我建议直接用Hash模式，省心不折腾。

4. 常见问题与排查技巧实录

4.1 时间冲突判断为什么总是捉妖

时间冲突判断是踩坑重灾区，我来复盘几个真实案例。

第一个问题是“我明明已经把那个时间段的数据删了，为什么还提示冲突”。排查思路：查看那张预约记录的状态字段，大概率是删除了物理记录，但还有一条状态为“已驳回”的记录存在。如果冲突SQL没有加状态过滤，这条“已驳回”的废记录就会成为一个永远横在那里的幽灵记录。

第二个问题是“查询空闲教室时，明明有教室空闲，却显示不在列表里”。这通常是SQL的NOT EXISTS子查询条件写错，最常见的是遗漏reservation_date日期条件，导致前天的、上周的占用记录也被算进去，那么所有教室在“昨天有使用过”的教室就都不可用了，简直离谱。

第三个问题是时间格式的比较问题。如果startTime和endTime在数据库里用的是time类型，但在Java里用LocalTime接收，比较结果一般没问题。如果你在某个地方把时间转成了String再比较，那"9:00"和"09:00"的字符串排序结果可能和你预期的不一样。我建议整个项目的时间类型保持统一，数据库用time和datetime，Java统一对应LocalTime和LocalDateTime，不要用Date混搭。

4.2 SpringBoot版本太高引发的连锁反应

热搜词里有个“springboot版本太高”，这绝对是许多学生心头的痛。常见痛点是：SpringBoot 3.x搭配旧版MyBatis-Plus 3.4.x，会直接启动报错。原因很简单，SpringBoot 3.x基于Jakarta EE，包名都从javax.*改成了jakarta.*，旧版MyBatis-Plus还没适配。

还有SpringSecurity版本升高后，一些默认配置也变了。比如SpringBoot 2.7之前默认放行所有请求，需要自己配置拦截规则；3.x之后Spring Security要求显式配置任何请求的鉴权规则，否则所有接口都会被拦下。很多同学把依赖加进去后发现自己写的接口全403了，就是踩了这个坑。

给毕设一个极其稳妥的版本组合：

JDK不建议直接用17，虽然SpringBoot 2.7也支持，但很多老版本的Maven插件和第三方依赖对JDK17支持得并不好，还在用JDK8的老电脑比比皆是。

4.3 后端接口联调时的跨域问题

联调阶段，前端跑在8081端口，后端跑在8080端口，浏览器的同源策略会让请求被拦截，报错信息是经典的Access-Control-Allow-Origin。解决方案很直接——在后端配置一个跨域过滤器。

最省事的做法：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意allowedOriginPatterns("*")和allowCredentials(true)搭配，这是SpringBoot 2.4之后的标准写法。如果你用allowedOrigins("*")并同时开启allowCredentials(true)，会抛异常。这也是一个高频踩坑点。

还有一种场景是在自定义拦截器里设置跨域头，结果发现根本没有生效。因为OPTIONS预检请求在Tomcat层面就被处理了，但如果你拦截器里对OPTIONS请求直接放行且没写响应头，前端照样跨域失败。所以用上面这个WebMvcConfigurer实现是最规范的。

4.4 打包部署之后前端样式丢失

有一种典型现象：本地运行npm run dev一切正常，npm run build后放到后端static目录，刷新发现页面全乱、图片不显示。

原因就一个——前端资源的绝对路径配置错误。Vue项目默认的base路径是/，如果你的后端项目本身部署在根路径下就没问题，但如果部署在Tomcat的某个应用子路径下，就需要把base设置为./或对应的子路径。特别是用了Vue CLI脚手架的话，在vue.config.js里设置：

module.exports = { publicPath: './' }

设置成相对路径后，打包出来的index.html里引用的JS和CSS就是相对路径，放到任何目录下都能正常加载。另外如果使用了路由的History模式，打包后部署到子路径也要同步修改路由的base，否则路由跳转同样会404。

4.5 数据库时间字段与Java类型的映射

MyBatis-Plus对LocalDateTime和LocalTime的支持是比较到位的，但仍有一个常见坑：在实体类里用字符串String接收数据库的datetime字段。这在查询时没错，但写入时String类型是不会被自动转换为datetime的，除非你在SQL里显式STR_TO_DATE，否则就会报Data truncation。

另一个坑是时区问题。MySQL连接串里不加serverTimezone=Asia/Shanghai，经常会报错或者时间差8小时。我习惯在application.yml里这样写：

spring: datasource: url: jdbc:mysql://localhost:3306/classroom?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

4.6 前端传参格式对不上

还有一个看起来低级但特别常见的bug：LocalTime类型的时间参数，SpringBoot默认的Jackson反序列化不支持接收"18:30"这种字符串，会报错。解决方法是写一个全局的Jackson配置：

@Bean public Jackson2ObjectMapperBuilderCustomizer customizeJackson() { return builder -> { builder.simpleDateFormat("yyyy-MM-dd HH:mm:ss"); builder.deserializers(new LocalTimeDeserializer(DateTimeFormatter.ofPattern("HH:mm"))); builder.serializers(new LocalTimeSerializer(DateTimeFormatter.ofPattern("HH:mm"))); }; }

也可以在前端直接把时间格式化为"18:30:00"这样完整的格式，后端使用默认规则解析。总之，前后端的时间格式必须约定好，不能前端发个18:30后端按18:30:00解析，那绝对会报错。

5. 答辩准备与项目进阶方向

5.1 答辩时老师最喜欢问什么

经历过很多次毕设答辩，我总结出老师对这类项目的高频提问点和对应的准备方向。

第一类问题关于设计思路：“为什么选用SpringBoot？为什么选择MyBatis-Plus而不是MyBatis？”你要能说出来SpringBoot的自动装配机制、约定优于配置的思想、内嵌Servlet容器的优势；也要能如实说MyBatis-Plus怎么帮你减少CRUD样板代码，它的BaseMapper提供了哪些通用方法。

第二类问题关于核心功能实现：“怎么做时间冲突检测的？如果两个人同时提交同一个教室的预约会怎样？”这道题直接考察你是否真正理解自己的代码。你要能讲清楚start_time < new_end AND end_time > new_start这个条件，还要能说出并发场景下应用层校验不是百分百安全，需要配合事务或者数据库锁。能被问到这里，说明老师觉得你的项目是真实做出来的。

第三类问题关于安全性：“密码明文存储吗？接口能被人直接调用吗？”准备思路是说明自己用BCrypt加盐哈希存储密码，使用JWT做无状态认证，用拦截器校验请求头中的token，并对管理员接口做了角色校验。

第四类问题关于后续改进：“你觉得这个系统还有什么地方可以优化？”不要傻乎乎地说“没有优化空间了”，可以提：引入Redis缓存教室空闲状态、引入消息队列提升并发下预约请求的削峰能力、生成二维码实现扫码签到、与教务系统课表数据打通避免与正式课程冲突。

5.2 让系统从“普通”到“出彩”的三个进阶方向

第一个是对接课表排课数据。智慧教室预定系统最大的局限在于没有考虑正式课程占用的教室。现实中周一到周五的某些时段，教室可能被学校统一排课占用，这个教室就不能对外开放预约。升级方案是增加一张course_schedule表存储固定占用时间，在空闲查询时把课表占用也视为不可预约时间段。这个功能一加，系统的实用性和答辩含金量立刻上一个档次。

第二个是增加Redis缓存。把教室列表、各时间段空闲状态缓存到Redis，设置合适的过期时间，降低数据库查询压力。这个方向适合想在技术深度上加分的人，实现代价不大，只要引入Redis依赖，在查询接口上加缓存逻辑即可。

第三个是引入数据可视化统计。基于预约记录统计各类教室使用率、高峰时段分布、热门教室排行榜，前端用ECharts画出图表。这一块在很多项目里属于“人无我有”的亮点，老师看了会觉得你这系统有完整的数据闭环。

5.3 最终建议：把时间分配好，别只盯着代码

做这种毕设项目，最忌一上来就敲代码，或者一直想“我要做得特别牛”。合理的节奏是：先花两三天把需求文档和数据库表设计好，再花一周把后端核心接口写完，再花一周把前端页面调完，最后留几天时间部署、测试和准备答辩PPT。每一步做完就跑通一遍，不要到时候攒了一堆bug到临近提交才开始改，那感觉简直生不如死。

我个人在做这类项目时的习惯是每写完一个模块，就顺手写一份简单的接口测试文档，用postman导出成JSON保存下来。答辩前再跑一遍所有接口，确认没有启动报错、没有依赖版本冲突、前端页面在部署环境下能正常打开。这些基础检查做好了，答辩心态就踏实了一大半。

这两年带学生做毕业设计，感触最深的是：查重、行业大环境虽然卷，但一个从需求出发、真真实实做出来的项目，配合你能讲清楚每一步为什么这样做，照样能在答辩现场拿到不错的成绩。教室预定系统这个题目也许不算“新奇特”，但把那些细节打磨到位，把冲突检测、事务边界、权限控制这些关键点讲透彻，它就是一个完整的、高质量的软件工程实践项目。

最后再分享一个小妙招：写论文的“系统实现”章节时，不用堆一堆代码截图，而是配上核心接口的调用时序和关键表结构说明，把每个模块的异常情况和处理逻辑写清楚，比粘贴大段无意义代码有用得多。这部分写好了，不仅论文老师觉得充实，答辩时你照着自己的文档回顾项目脉络，也不容易紧张卡壳。