会议室预约这件事，我在企业里见得太多了。行政在微信群里发Excel表格，大家接龙填时间；或者墙上贴一张纸质排期表，谁要用就先来登记，结果经常出现两个部门同时约同一个会议室，到了现场才发现撞了。做了这么多年管理系统，我越来越觉得这类“看起来简单”的预约系统，真正做好很考验对业务的理解。SpringBoot+Vue这个技术栈，在会议室预约管理系统里用得非常多，也特别适合作为计算机毕业设计的选题——业务流程清晰、技术栈主流、前后端分离的架构还能体现完整的工程能力。这篇就基于一个我实际带过的毕设项目来聊，从需求拆解、数据库设计、核心代码到踩坑实录，把整个系统的关键细节全部讲透。
这个项目解决的核心问题很实在：企业会议室和活动场地的信息不透明、预订冲突率高、审批流程混乱、使用率无法统计。系统做出来之后，员工能在线查看所有场地的空闲状态、按需下单预订，管理员可以审批、管理房间、统计使用情况，整个流程全部线上闭环。如果你正在准备毕设，或者刚入行想找一个前后端分离的完整实战项目练手，这篇内容应该能帮你省掉不少查资料的功夫。
1. 项目整体设计与技术选型思路
1.1 一个会议预约系统要解决的核心矛盾
动手写代码之前，我习惯先搞清楚一个问题：这个系统到底在解决什么矛盾？
会议室管理的本质矛盾是“资源有限、需求随机、信息分散”。资源有限是指一个公司会议室数量固定，尤其是大会议室和带投屏设备的会议室，更是稀缺资源；需求随机是指员工开会时间不固定，经常有临时会议、客户到访需要临时订房；信息分散是指如果没有统一的系统，会议室占用情况只存在于某个人的脑子里或者某个Excel文件里，别人根本看不到。
这三个痛点叠在一起，就推导出了系统必须满足的四项核心能力：可见性，所有场地状态在系统内实时可查；排他性，同一时间一个场地只能被一个预订占用；可追溯性，谁在什么时间订了哪个会议室，历史记录清晰可查；可分析性，能统计出场地的使用率、高峰时段，为行政优化资源配置提供数据支撑。
我看过很多毕设版本的会议室系统，功能罗列得挺多，但很多都忽略了排他性和可分析性这两个核心点，导致做出来像个玩具。比如有的系统预订时不查冲突，管理员手动协调，这就是没抓住矛盾本质。所以真正动手设计之前，先把这四个核心能力想清楚，后面每写一个功能都能对得上号。
1.2 为什么选SpringBoot+Vue而不是其他组合
技术选型这部分，每年都有同学问我：学长，用SSH行不行？用JSP加Servlet行不行？或者干脆做个纯前端行不行？
先说结论：SpringBoot+Vue是目前最适合做这类管理系统的组合，没有之一。
分析一下各方案的利弊就明白了。SSH（Struts+Spring+Hibernate）是十年前的技术，配置繁琐得让人崩溃，现在市面上大部分公司早就不用了，拿它做毕设不仅自己写得痛苦，答辩老师看到技术栈也会觉得过时。JSP+Servlet虽然能跑，但前后端耦合在一起，页面逻辑混乱，改一个按钮要找半天代码，而且没法体现“前后端分离”这个现代Web开发的核心思想。
SpringBoot这边，核心优势是“约定大于配置”，内嵌Tomcat容器，不用额外部署WAR包，直接一个jar包就能跑起来。配合MyBatis-Plus操作数据库，CRUD代码量能省掉一大半。而且SpringBoot是当前国内企业使用率最高的Java框架，面试的时候这个项目写在简历上，HR和技术面都认。
Vue这边，核心优势是上手曲线平缓，双向绑定和组件化开发让前端逻辑非常清晰。对毕设来说，你不需要掌握特别深的前端工程化知识，会用Vue Router做路由跳转、会用Axios调后端接口、会用Element UI搭建页面，就已经完全足够撑起一个合格的前端了。
还有一个实际考量：前后端分离架构本身就是加分项。答辩的时候你能讲清楚“前端通过RESTful API与后端交互，后端只负责业务逻辑和数据持久化”，这在老师眼里就是有工程意识的体现。而且这个架构天然便于扩展，以后想加一个小程序端，直接复用后端的接口就行了。
1.3 功能模块拆解：从用户角色倒推
需求设计有一个好办法：先确定系统里有哪几类角色，然后倒推每个角色需要什么功能。
这个系统涉及两类角色，普通员工和管理员。我不建议把角色拆得太细，比如加一个“部门主管”做二次审批，对毕设来说会显著增加开发量，而且业务逻辑容易变得混乱。两类角色刚刚好，既能体现权限控制的思路，又不至于把自己绕进去。
普通员工端功能清单：
- 查看所有会议室/活动场地的列表、详情、设备情况
- 查看某个场地在指定日期的时间轴占用情况
- 发起预订申请，选择场地、时间、填写会议主题、参会人数
- 查看自己发起的预订记录及审批状态
- 取消未开始的预订
管理员端功能清单：
- 场地管理：新增、编辑、禁用会议室，维护容量、设备、图片信息
- 预订审批：通过或驳回待审核的预订申请
- 预订总览：查看全公司所有预订记录，按日期、场地、状态筛选
- 数据统计：按周/月统计场地使用率、预订高峰时段
- 用户管理：查看用户列表、禁用异常账号
再往上一层，还有一个复合型活动基地的抽象问题。标题里写的是“会议室预订系统”，但实际业务里除了会议室，还有培训室、路演厅、员工活动室等不同类型的场地。在设计数据库的时候，我建议用“场地类型”字段来区分，而不是为每种场地单独建表。这样一个系统就能同时管理会议室、培训室、活动室，管理员新增场地时选择类型即可，后续扩展完全不用改表结构。
1.4 接口设计里的“复合”思考
说到“复合型活动基地”，我再多说一句接口层面的设计。很多毕设的接口都是“一功能一接口”的写法，比如查会议室列表一个接口、查培训室列表又一个接口，这种设计会导致前端代码大量重复。
正确的做法是用抽象的资源路径来设计接口。租用场地和会议室本质上是同一种行为，完全可以用一个预订接口来表达，通过路径参数或请求体里的字段来区分场地类型。这样做的直接好处是前端可以复用一套预订组件，后端也不需要维护两套几乎相同的业务逻辑。
我在这个项目里定的接口风格是RESTful风格，例如GET /api/rooms获取场地列表，POST /api/reservations提交预订申请，PUT /api/reservations/{id}/approve进行审批，DELETE /api/reservations/{id}取消预订。统一风格的接口，前端对接的时候不需要来回看文档猜逻辑，答辩展示的时候也能讲出设计感。
2. 核心功能实现与数据库设计
2.1 数据库表结构设计思路
数据库设计是这类系统的灵魂。我见过有同学的毕设只建两张表，一张用户表一张预订表，会议室信息写死在代码里。这样倒也能跑，但老师问一句“管理员怎么新增会议室？”就答不上来了。规范的数据库设计至少要包含四张核心表。
用户表（sys_user）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| username | varchar(50) | 登录名，唯一 |
| password | varchar(100) | BCrypt加密后的密码 |
| real_name | varchar(50) | 真实姓名 |
| phone | varchar(20) | 联系电话 |
| role | tinyint | 角色：0普通用户，1管理员 |
| status | tinyint | 状态：0正常，1禁用 |
| create_time | datetime | 创建时间 |
| deleted | tinyint | 逻辑删除标记 |
user表设计要点是role字段要放在用户表里而不是单独建角色表，因为系统只有两类角色，单独建表属于过度设计，对于毕设来说反而增加了没必要的关联查询复杂度。password字段必须用BCrypt加密存储，千万不能明文保存，这点答辩时经常被问到。
场地表（meeting_room）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| room_name | varchar(100) | 场地名称 |
| room_type | tinyint | 场地类型：1会议室，2培训室，3活动室 |
| location | varchar(200) | 所在位置，如“A栋3楼301” |
| capacity | int | 可容纳人数 |
| equipment | varchar(500) | 设备清单，逗号分隔，如“投影仪,视频会议,白板” |
| picture | varchar(500) | 图片URL |
| status | tinyint | 状态：0可用，1禁用 |
| create_time | datetime | 创建时间 |
| deleted | tinyint | 逻辑删除标记 |
equipment字段用逗号分隔的字符串来存，很多同学喜欢单独建一张设备表然后做多对多关联，但实际使用中设备信息只是用来展示，根本不需要单独查询设备维度，字符串存储已经足够了。
预订表（reservation）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| user_id | bigint | 预订人ID |
| room_id | bigint | 场地ID |
| meeting_name | varchar(200) | 会议/活动主题 |
| start_time | datetime | 开始时间 |
| end_time | datetime | 结束时间 |
| status | tinyint | 状态：0待审核，1已通过，2已驳回，3已取消，4已完成 |
| remark | varchar(500) | 备注 |
| audit_user_id | bigint | 审核人ID |
| audit_time | datetime | 审核时间 |
| create_time | datetime | 创建时间 |
| deleted | tinyint | 逻辑删除标记 |
reservation表是整个系统的核心，字段设计上有两个关键点。第一，audit_user_id和audit_time这些“审核痕迹”字段一定要保留，这体现的是可追溯性。第二，status字段用整型枚举，不要直接用字符串存“已通过”“待审核”这类中文，数据库层面只用数字，对应的中文含义在代码枚举类里定义。
通知表（notification）属于扩展表，用于站内信功能。字段包括id、user_id（接收人）、content（通知内容）、is_read（是否已读）、create_time。如果不想做站内信，这一张表可以省略，但加上之后功能完整度会明显提升。
2.2 预订状态机与核心业务规则
预订状态机是这类系统的业务引擎，设计得好不好直接决定了代码的复杂度。
我在这个项目里定义了五个状态：待审核、已通过、已驳回、已取消、已完成。对应的状态流转规则是：
- 用户提交预订 → 待审核
- 管理员通过 → 已通过
- 管理员驳回 → 已驳回
- 用户取消/超时未审核系统自动取消 → 已取消
- 会议结束时间已过且状态为已通过 → 已完成
状态机在代码层面的落地方式是：定义一个预订状态枚举类，所有涉及状态变更的方法都走这个枚举定义的流转规则，不允许业务代码里直接改状态数值。
这样做的最大好处是防止“非法跳转”。比如一个已经取消的预订不能被管理员通过，一个已完成的预订不能被再次取消——这些非法操作如果靠每个接口自己判断，很容易漏，用状态机统一收口就能彻底避免。
另外还要定义一条核心业务规则：预订必须基于时间段，且结束时间必须晚于开始时间，预订时长不能超过系统设定的最大值（比如4小时）。前端可以做个校验提示用户，但真正可靠的校验必须在后端做，因为前端校验可以被绕过。这条规则在预订接口事务里用代码强制校验，不满足就抛业务异常。
2.3 冲突检测的两种实现方案
会议室系统最硬的骨头就是冲突检测，也就是“这个时段这个会议室是否已经被占用”。
我整理出两种方案供参考，实际开发中我推荐第一种。
方案一：数据库条件查询冲突（推荐）
利用了区间重叠的判断逻辑：两条预订有冲突，当且仅当existing_start_time < new_end_time且existing_end_time > new_start_time。
对应的SQL写法：
SELECT COUNT(*) FROM reservation WHERE room_id = #{roomId} AND status IN (0, 1) -- 待审核、已通过视为占用 AND start_time < #{endTime} AND end_time > #{startTime} AND deleted = 0如果查询结果大于0，说明存在冲突，直接拒绝本次预订。
这段SQL的理解关键在于：判断两个时间段是否重叠，不需要写复杂的条件组合，只用“旧开始小于新结束 且 旧结束大于新开始”这一个条件就够了。比如旧时间是9点到11点，新时间是10点到12点，旧开始9 < 新结束12 成立，旧结束11 > 新开始10 也成立，所以判定冲突，符合直觉。
方案二：应用层内存锁检测
在代码里加锁，比如用ReentrantLock对同一个roomId加锁，保证同一个会议室的预订请求串行化处理，然后依次判断是否有冲突。这个方案在单机场景下能用，但是性能较差，而且如果系统扩展成多实例部署，本地锁就失效了。对毕设来说，方案一配合数据库索引已经足够。
性能优化的关键是在reservation表上建联合索引。推荐的索引是(room_id, start_time, end_time)，这样冲突检测的WHERE条件能直接走索引，数据量大了也能扛得住。
2.4 数据库初始化数据的设计
系统开发阶段一定要准备合理的初始化数据，这样前端页面才能展示出效果，调试起来也方便。
我建议准备以下数据：3到5个不同类型的场地，比如小会议室（容纳6人）、大会议室（容纳20人）、培训室（容纳30人）、活动室（容纳10人）；管理员账号一个，普通用户账号两三个；过去一周到未来一周的预订记录若干条，覆盖待审核、已通过、已取消、已完成等多个状态。
初始化数据不是随便编几条就行。预订记录里的时间要与真实的“当前时间”相关，保证你打开系统首页就能看到“进行中的会议”“即将开始的会议”这些动态模块有效果。如果数据都是上个月的，页面展示出来就会显得很假。
3. 实操过程与核心环节实现
3.1 SpringBoot项目初始化与依赖选择
用IDEA创建SpringBoot项目，我遇到过最多的问题是创建超时——Spring Initializr服务连不上。解决办法是换成阿里云镜像地址，在IDEA的HTTP Proxy设置里填上阿里的初始化服务地址，创建速度能快出好几倍。
创建项目时勾选的依赖：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>4.4.0</version> </dependency> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.18</version> </dependency>这里做的取舍是：JWT用java-jwt这个轻量库而不是Spring Security，因为引入完整的Spring Security安全框架，配置过程会牵扯到SecurityConfig、过滤链、认证管理器等一堆概念，对毕设来说学习成本太高且容易出错。java-jwt的基本用法就是签发和校验，两百行左右代码就能实现完整的登录鉴权，足够用了。
另一个取舍是用MyBatis-Plus而不是原生MyBatis。MyBatis-Plus内置了通用的CRUD方法，比如selectById、selectPage，单表查询完全不用自己写SQL，能省掉大量重复的Mapper XML配置。只有涉及多表关联查询时才需要手写SQL。
3.2 登录鉴权与JWT令牌设计
登录鉴权这块我详细说一下，因为这是前端每次请求都会触发的逻辑，做不好整个系统都跑不顺。
登录接口逻辑：
流程是：前端传用户名和密码，后端先查用户是否存在、状态是否正常，然后用BCrypt校验密码，密码正确就生成JWT令牌返回给前端。
关键代码：
@Service public class UserServiceImpl implements UserService { @Override public String login(String username, String password) { LambdaQueryWrapper<SysUser> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(SysUser::getUsername, username); SysUser user = userMapper.selectOne(wrapper); if (user == null) { throw new BusinessException("用户不存在"); } if (user.getStatus() == 1) { throw new BusinessException("账号已被禁用"); } if (!BCrypt.checkpw(password, user.getPassword())) { throw new BusinessException("用户名或密码错误"); } // 生成JWT令牌，有效期8小时 String token = JWT.create() .withAudience(String.valueOf(user.getId())) .withClaim("username", user.getUsername()) .withClaim("role", user.getRole()) .withExpiresAt(new Date(System.currentTimeMillis() + 8 * 60 * 60 * 1000)) .sign(Algorithm.HMAC256(secretKey)); return token; } }为什么要用BCrypt而不是MD5加密密码？这是一个高频面试题。MD5是摘要算法，不是专门为密码存储设计的，暴力破解成本极低，网上还有巨大的彩虹表可以直接反查。BCrypt是自适应哈希算法，内部引入随机盐值，同一个密码每次加密结果都不同，并且计算速度可以调整，即使数据库泄露，攻击者破解的成本也高得多。记住这个逻辑，答辩时能加不少分。
后端拦截器统一验证Token：
定义一个HandlerInterceptor，在所有非登录接口的请求进来时先校验Header里的Token，校验通过就把用户信息放入ThreadLocal，方便后续业务代码直接获取当前登录用户。
public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (StrUtil.isBlank(token)) { throw new BusinessException(401, "未登录"); } try { DecodedJWT jwt = JWT.require(Algorithm.HMAC256(secretKey)).build().verify(token); Long userId = Long.valueOf(jwt.getAudience().get(0)); UserContext.set(userId); } catch (Exception e) { throw new BusinessException(401, "登录已过期"); } return true; } }这里有一个坑必须提醒：不要用try-catch把过期异常给吞了。JWT过期后verify会抛出JWTVerificationException，如果这里不捕获，而是直接往外抛，前端能清晰地收到401状态码，然后自动跳转登录页。如果捕获了继续放行，那Token校验就形同虚设了。
前端配合的逻辑：Axios拦截器对响应状态码做统一处理，当返回401时，清除本地存储的Token并跳转到登录页面。
3.3 场地列表与时间轴查询实现
场地列表页是系统里最常用的页面，要展示什么信息、怎么写查询逻辑，也是有讲究的。
列表页展示内容：场地名称、类型标签、位置、容纳人数、设备图标、状态标签，以及最重要的——今天这个场地是否可订。
“是否可订”这个字段不能简简单单查房间status就完事，要联合当前时间来判断。核心逻辑是：房间未被禁用，且当前时间不在已通过的预订时间范围内。
这里推荐的做法是：查房间列表后，批量查询当天的有效预订，然后在Java内存里组装数据，而不是逐条联表查询。这样只需要两条SQL就搞定，避免N+1查询问题。
时间轴功能更有意思。用户选中某一天后，前端展示从早上8点到晚上22点的时间段，每个场地显示哪些时段已被预订。这个时间轴的数据获取其实很简单：通过start_time在选中日期的0点到24点、status为已通过这两个条件，查出当天有效预订，再按房间分组返回给前端。
3.4 预订与取消预订的核心事务逻辑
预订是高频操作，必须保证并发环境下的正确性。核心逻辑用代码来演示：
@Transactional(rollbackFor = Exception.class) public void createReservation(ReservationDTO dto) { // 1. 参数校验 if (dto.getStartTime().isAfter(dto.getEndTime())) { throw new BusinessException("结束时间必须晚于开始时间"); } if (Duration.between(dto.getStartTime(), dto.getEndTime()).toHours() > 4) { throw new BusinessException("单次预订时长不能超过4小时"); } // 2. 场地存在性校验 MeetingRoom room = roomMapper.selectById(dto.getRoomId()); if (room == null || room.getStatus() == 1) { throw new BusinessException("场地不存在或已被禁用"); } // 3. 冲突检测 LambdaQueryWrapper<Reservation> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Reservation::getRoomId, dto.getRoomId()) .in(Reservation::getStatus, Arrays.asList(0, 1)) .lt(Reservation::getStartTime, dto.getEndTime()) .gt(Reservation::getEndTime, dto.getStartTime()); Long count = reservationMapper.selectCount(wrapper); if (count != null && count > 0) { throw new BusinessException("该时间段已被预订，请选择其他时间"); } // 4. 保存预订 Reservation reservation = new Reservation(); reservation.setUserId(UserContext.getUserId()); reservation.setRoomId(dto.getRoomId()); reservation.setMeetingName(dto.getMeetingName()); reservation.setStartTime(dto.getStartTime()); reservation.setEndTime(dto.getEndTime()); reservation.setRemark(dto.getRemark()); reservation.setStatus(0); // 待审核 reservationMapper.insert(reservation); }三个容易被忽视的细节：
@Transactional(rollbackFor = Exception.class)必须写。Spring默认只在遇到RuntimeException时回滚事务，如果业务代码抛的是自定义Exception，不配置rollbackFor的话事务不会回滚，就会出现冲突检测通过但插入失败却把前面影响的数据留下来了。
冲突检测和插入必须在同一个事务里。如果在事务外先查询再另开事务插入，两个并发请求可能同时查到“无冲突”，然后都插入成功，这就产生了脏数据。事务的隔离性可以保证同一时刻只有一个请求在写数据库，所以把查询和插入放一个事务里是并发安全的。
取消预订的逻辑相对简单，就是校验当前用户是预订人或者当前用户是管理员，然后将status改为3（已取消）。这里要注意取消操作必须校验预订状态只能是0或1，如果预订已经完成，就不能再取消了。
3.5 管理员端：审批与统计报表实现
管理员端要写出真正能用的感觉，两个功能是关键：审批操作和数据统计。
审批逻辑：管理员对待审核的预订点“通过”或“驳回”。通过时，再次做一个冲突检测——这一点容易被忽略，因为待审核期间可能已经有别的预订抢先通过了，不重新检测就会出现“先审批通过、后得知该时段已满”的情况。
审批通过之后的顺序是：更新预订状态和审核信息 → 往notification表插入一条站内信通知用户“您的预订已通过”。
统计报表SQL示例：
统计本周各天的预订数量：
SELECT DATE_FORMAT(start_time, '%Y-%m-%d') AS days, COUNT(*) AS count FROM reservation WHERE status = 1 AND start_time BETWEEN #{startDate} AND #{endDate} GROUP BY DATE_FORMAT(start_time, '%Y-%m-%d') ORDER BY days统计各场地使用率：
SELECT r.room_name, COUNT(res.id) AS booked_count, SUM(TIMESTAMPDIFF(MINUTE, res.start_time, res.end_time)) AS booked_minutes FROM meeting_room r LEFT JOIN reservation res ON r.id = res.room_id AND res.status = 1 AND res.start_time BETWEEN #{startDate} AND #{endDate} GROUP BY r.id, r.room_name这里用LEFT JOIN而不是JOIN，是为了把没有预订记录的场地也显示出来，使用率为0。前端拿到数据后，用图表库（ECharts）渲染成柱状图和折线图，展示效果很好。
导出Excel功能用EasyExcel实现比较简单。引入依赖后，定义好实体类上的注解，调用EasyExcel.write方法直接把查询结果写入响应流。这里有一个特别容易踩的坑：导出时设置响应头必须包含编码格式，否则Excel里的中文会是乱码。
response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setCharacterEncoding("utf-8"); String fileName = URLEncoder.encode("预订统计", "UTF-8").replaceAll("\\+", "%20"); response.setHeader("Content-disposition", "attachment;filename*=utf-8''" + fileName + ".xlsx");3.6 Vite前端项目结构与跨域配置
前端的工程结构建议这样组织：
src/ ├── api/ # 接口封装 │ ├── room.js │ └── reservation.js ├── router/ # 路由配置 ├── store/ # Pinia或Vuex状态管理 ├── views/ # 页面组件 │ ├── login.vue │ ├── room-list.vue │ ├── room-detail.vue │ ├── reservation-list.vue │ └── admin/ │ ├── room-manage.vue │ ├── approval.vue │ └── statistics.vue └── utils/request.js # Axios请求封装开发环境跨域问题，我建议在Vite配置文件里配代理，这样前端请求的路径是相对路径，由Vite Dev Server转发给后端，彻底规避浏览器跨域限制。
// vite.config.js server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }生产环境部署的时候，跨域问题要用后端配置解决，两种方式任选：一是后端加CORS过滤器，二是在Nginx配置反向代理，把/api路径转发到后端地址。毕设演示通常是在本地跑开发环境，用Vite代理就够了。
登录状态管理用Pinia存储用户信息和Token。Token同时要存一份到localStorage，刷新页面后从localStorage恢复状态，并写在axios的请求拦截器里，每次请求自动带上Authorization头。
3.7 半自动批量导入初始化数据
答辩演示的时候，如果数据库里只有几条测试数据，页面展示会显得空。我建议写一个CommandLineRunner，在应用启动时自动检查数据量，如果为空就初始化一批完整数据，包括场地、用户和一段历史的预订记录。
批量导入预订数据时要注意冲突检测，不能直接全部insert，可以先关掉自动提交，一次写入整个批次的数据，然后统一判断。这里简单实现就是循环调用业务层的createReservation方法，因为该方法内部有冲突检测逻辑，能保证数据不冲突。
这个初始化功能放在一个单独的配置类里，正式环境可以配置成不执行。对毕设来说，这个功能的价值在于答辩前不用手动造数据，重启项目就能看到效果，非常省事。
4. 常见问题与排查技巧实录
4.1 时间冲突检测失效的三个原因
这个Bug我在很多项目里见过，排查时优先检查三点。
第一，SQL条件写反了。有些同学写的是查“已有预订与本次预订完全不相交”的记录，而不是查“相交”的记录，导致反向过滤反了，越冲突越能订。正确写法就是上面那个start_time < new_endTime AND end_time > new_startTime，这个条件对应的是“交集非空”。
第二，数据库字段类型用错了。start_time字段在MySQL里必须用datetime类型，不能图省事存成varchar。用字符串比大小查询时间区间，遇到跨日、跨月的时候结果会出错，而且性能特别差。
第三，并发场景校验失效。如果冲突检测和插入操作不在同一个事务里，两个并发请求会同时读到“无冲突”数据，然后各自插入成功。解决办法就是把冲突检测和插入放到同一个@Transactional方法里。
4.2 会议室禁用后仍然被预订
场地状态分为可用和禁用。管理员把某场地禁用了，但用户端还能搜索到它并提交预订，这是因为查询场地列表时没有加上场地状态的过滤条件。
排查思路：搜索场地的接口，SQL里有没有加AND r.status = 0？预订接口里，保存预订前有没有再次校验场地的当前状态？这两个地方都要改。另外，禁用场地时最好把该场地“待审核”状态的预订全部自动取消，否则管理员禁用了场地，之前累积的待审核预订仍然占着坑位。这一步可以用一个批量update语句实现，给管理员操作加上明确提示。
4.3 事务不生效的隐蔽场景
@Transactional不生效，最常见的三种情况：
- 同类内部方法调用：A方法调B方法，两个方法在同一个类里，B上的@Transactional不会被Spring代理拦截。解决办法是把B方法拆到另一个Service类中，或者用注入自身代理的方式调用。
- 异常被吞掉了：方法内部用try-catch捕获了异常不往外抛，事务管理器感知不到异常就不会回滚。正确的做法是捕获到异常后记录日志并抛出RuntimeException，或者干脆不catch让异常向上抛。
- 非public方法：Spring事务代理只对public方法生效，写private方法上的@Transactional形同虚设。
排查事务问题的方法是打开日志，把事务执行情况输出到控制台，能直接看到什么时候开事务、什么时候提交/回滚。
4.4 前端页面刷新后404和后端跨域报错
前端路由如果用history模式，部署到服务器后，用户直接访问http://域名/some-path，服务器找不到该路径对应的文件，就会返回404。这是因为history模式下路由由前端控制，nginx并不知道这个路径的存在。
解决办法有两个：一是把Vue Router改回hash模式，URL会多一个#号，但刷新不会404，对毕设来说是最省事的方案；二是配nginx的try_files指令，让所有路径都回退到index.html，由前端路由接管。
location / { try_files $uri $uri/ /index.html; }跨域报错的排查点：后端有没有配置CORS？前端请求的地址是相对路径还是完整域名？如果一个是localhost:8080一个是localhost:5173，前后端各自独立跑起来，就必须有跨域处理机制，否则浏览器会拦截响应。开发环境用Vite代理，生产环境用Nginx反代，这两个都在上面讲过了。
4.5 导出Excel中文乱码与时间差8小时
导出的Excel打开后中文全是乱码，原因基本可以锁定是响应头缺少编码设置。按上一节写的响应头格式来设置就能解决。
时间差8小时是另一个高频问题。原因链是：MySQL连接串没有指定时区，JVM默认时区是UTC（有的服务器是），北京时间比UTC早8个小时，数据库存的是UTC时区的时间，展示出来就差了8小时。解决办法是在JDBC连接串中显式添加服务器时区参数。
spring.datasource.url=jdbc:mysql://localhost:3306/meeting_room?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai4.6 权限控制漏洞：普通员工调用管理员接口
很多毕设的前端菜单会根据角色动态隐藏，但接口层面没有任何控制。这在实际项目里很致命——普通用户在浏览器里用开发者工具就能直接构造请求，调用管理员的接口。
防御措施：后端写一个简单的角色校验注解，比如@RequireRole("admin")，在Interceptor里解析Token，取出当前用户角色后校验权限。核心接口全部加上这个注解，保证即使前端被绕过，后端也能拦截。
@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String value() default "admin"; }然后写一个拦截器解析这个注解，逻辑是：如果方法上有@RequireRole注解，就校验当前登录用户的角色是否为注解指定的角色，不满足就返回403。
5. 部署与答辩演示的实操技巧
5.1 打包部署的基本流程
毕设项目最终要能演示，我建议提前一周就把完整流程跑通，避免现场出状况。
后端部分：在项目根目录执行mvn clean package -DskipTests，会在target目录生成一个jar包。直接在服务器或本机执行java -jar meeting-room-server.jar，只要数据库配置正确，应用就能启动。这里的要点是修改application.yml中的数据源配置和文件上传路径为绝对路径。
前端部分：在项目目录执行npm run build，会在dist目录生成静态文件。将dist目录下的所有文件复制到nginx的html目录，并配置好代理规则，把/api开头的请求转发到后端服务的地址。
5.2 答辩演示路径设计
答辩演示不要在所有页面上平均用力，我建议设计一条从事件到结果的演示路径。
登录的时候用管理员账号登录，先进入管理后台，展示“本周预订统计”仪表盘，让老师直观看到系统有数据支撑能力。然后进入场地管理，展示步骤：新增一个场地，再去预约页面演示这个新场地出现在列表中。接着到审批页面，用普通用户账号演示发起预订，再用管理员账号审批通过。整个流程环环相扣，演示本身就证明了系统的完整性和业务逻辑闭环。
最后可以演示一个反例，故意选择一个已被占用的时间段提交预订，前端会提示时间冲突。这个反例的展示效果比正例更好，它说明系统不是只在顺境下能用，异常处理也是完备的。
5.3 答辩高频问题与回答思路
准备答辩时，把下面这些问题提前想好答案，现场会稳很多。
“为什么选择SpringBoot而不是SpringMVC？”——SpringBoot是SpringMVC的后继整合方案，内嵌容器、自动配置、快速启动，是当前企业主流选择。
“为什么用JWT而不用Session？”——前后端分离架构下Session需要处理跨域Cookie问题，而且Session存储在服务端内存里，服务多实例部署时还需要引入Redis做Session共享。JWT是自包含的令牌，服务端不需要保存会话状态，天然支持水平扩展。
“这个系统的并发性能如何？”——数据库索引和事务设计保证了单机的并发安全性。如果想进一步提升，可以引入Redis缓存场地空闲状态，或者将冲突检测迁移到Redis分布式锁，这些都是当前系统设计的预留扩展点。
“你在这个项目里遇到的最大困难是什么？”——可以回答并发场景下时间冲突检测的准确性，展开讲排查过程和处理方案，这正是这个项目的核心难点，老师一般会认可你确实深入做过。
6. 项目打包配套资料与后续扩展建议
6.1 毕设资料包的规范整理
这个项目配套的程序、文档、讲解，整理时建议按下面的目录结构归档，方便自己查找，也方便指导老师审阅：
毕业设计_会议室预约管理系统/ ├── 01_程序源码/ │ ├── backend/ # SpringBoot后端源码 │ └── frontend/ # Vue前端源码 ├── 02_数据库/ │ └── sql/ # 建表语句和初始化数据 ├── 03_论文文档/ │ ├── 任务书.md │ ├── 开题报告.md │ ├── 中期检查.md │ └── 毕业论文.md ├── 04_演示视频/ └── 05_答辩PPT/论文写作的顺序不建议一开始就动笔，空想很难写出来。我建议流程是：先跑通系统，然后按模块截图，再按论文框架去写。每一步都配上实际截图，论文的可信度和完成速度都会大幅提升。
6.2 系统纵向扩展的三个方向
如果时间充裕，可以在核心功能之上加一两个亮点功能，面试时也是很好的谈资。
第一个方向是对接企业微信/钉钉通知。预订审批通过取消时，通过企业微信Webhook机器人推送通知，或者集成钉钉的审批流。这个方向能体现你了解真实企业的协作方式。
第二个方向是引入Redis做分布式锁和缓存。并发场景下把常用场地列表缓存到Redis，预订时通过Redis的SET NX命令实现分布式锁，保证多实例部署时冲突检测依然是安全的。
第三个方向是生成可视化数据大屏。把场地使用率、日均预订量、热门会议室排行、部门预订占比这些统计数据做成一个大屏页面，放在门厅屏幕上展示，视觉效果非常震撼，答辩演示时是绝对的加分项。
6.3 前端性能优化的小技巧
Vue项目在会议列表这类数据量较大的页面，渲染几千条DOM节点可能会卡顿。有两个低成本高收益的优化手段。
一个是懒加载图片。场地图片用loading="lazy"属性，或者用VueLazyload插件，页面滚动到对应位置时才加载图片，首屏加载速度会明显提升。
另一个是合理使用Vue的computed和watch的边界。不要在watch里做深度拷贝和复杂运算，数据提取逻辑放到computed里，Vue会对computed做缓存，只有依赖项变化时才重新计算。这个细节面试也常问，值得好好理解。
写在最后的一个建议
做这个项目的时候，我最大的感受是：真正的难点从来不是写代码，而是把业务流程想清楚的那一周。你花三天把数据库表和状态机设计得明明白白，后面的编码就是体力活；反过来，脑子一热直接开写，中途返工的成本往往是预期的两倍以上。我自己做的时候最满意的不是代码本身，而是把“审批状态机”和“冲突检测”这两个核心逻辑真正想透了。后来出去面试，面试官问这类业务系统的设计思路，我都能从这两个点切入，交流起来非常顺畅。你也值得把这个项目当成一次真实的工程训练，而不是仅仅当成一个要交差的作业。
