简介这是一套基于Java后端技术栈开发的智能化会议室预约管理系统完整项目面向计算机相关专业学生用于毕业设计或课程设计也适合希望掌握Spring Boot、MyBatis等主流框架的Java后端初学者。系统涵盖用户管理、会议室管理、预约管理、日程管理、提醒服务及系统设置等模块展示了从需求分析到编码实现、单元测试的完整开发流程。压缩包共613个文件包含92个Java源码、37个JSP页面、119个class编译文件、62个jar依赖库及51个CSS样式另含大量图片素材整体约47.64MB。目前已有95人学习下载适合作为理解企业级MVC架构、数据库设计与前后端交互的实战参考。通过阅读项目源码和配置读者可掌握Spring Boot整合MyBatis与Thymeleaf的具体实现方式学习时间冲突检测、权限控制等业务场景的编码技巧为独立完成类似系统开发提供直接借鉴。1. 智能化会议室预约管理系统不是交差而是能自己讲清楚的整套 Java 后端五月份是毕业设计答辩的高峰很多 Java 方向的同学下载到的所谓“毕设源码”要么是十几年前的 SSH 古董要么是前后端代码混成一团、启动三分钟就报错。这套智能化会议室预约管理系统是另外一类Spring Boot 做后端骨架MyBatis-Plus 操作数据库流程上把预约、冲突检测、审批、统计一条链走完。换句话说它不是只给你一个能截图的页面而是让答辩现场能讲出“系统怎么处理两个人同时抢一间会议室”这种核心问题。适合正在做毕业设计或课程设计、后端基础一般、需要能跑通又能讲原理的人。2. 项目结构与技术栈先看清 Spring Boot 集成 MyBatis-Plus 是怎么组织的2.1 资源包里有什么一份可以落地的 Maven 工程拿到压缩包后先别急着启动。先看根目录下的结构确认它是标准 Maven 工程而不是散件拼凑。一个合格的资源包至少应该包含后端的 Java 源码、SQL 初始化脚本、以及一份启动说明。本项目采用的是 Spring Boot 2.x 配合 MyBatis-Plus数据库是 MySQL 8.0。选择这三样组合的原因很直接Spring Boot 解决配置地狱MyBatis-Plus 解决手写大量 XML 的重复劳动MySQL 则在校园环境和答辩演示时最容易找到运行环境。依赖层面pom.xml 里除了 spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java还有一个很关键的 lombok。很多新手第一次编译失败就出在 lombok 上IDE 没装插件会导致实体类的 getter/setter 报错。建议在 IDEA 里打开 Settings确认 Annotation Processing 勾选了 Enable annotation processing。这是最常见的“代码没问题但编译不过”的坑。数据访问层选 MyBatis-Plus 而不是原生 MyBatis还有个实际好处分页插件、逻辑删除、自动填充时间都是内置的表结构设计得不太离谱的话基础 CRUD 可以不写一行 SQL。这对毕业设计来说意味着能把精力放在业务规则上比如冲突检测、审批流转而不是在 BaseMapper 里反复复制粘贴简单查询。2.2 后端分层目录从包名看懂这套系统的分层方式打开src/main/java下的包结构一般会按controller/service/mapper/entity/config/vo来分。这种分层不是毕业设计默认格式而是能直接回答答辩问题的结构。Controller 只做参数接收和结果封装Service 写业务规则Mapper 层只负责数据库交互Entity 对应表。如果你发现某个包里的类职责乱了比如 Service 里直接拼 SQL那后面排错时你会非常痛苦。com.school.meeting ├── controller │ ├── AuthController.java │ ├── RoomController.java │ └── BookingController.java ├── service │ ├── BookingService.java │ └── RoomService.java ├── mapper │ ├── UserMapper.java │ ├── RoomMapper.java │ └── BookingRecordMapper.java ├── entity │ ├── User.java │ ├── Room.java │ └── BookingRecord.java ├── config │ ├── MybatisPlusConfig.java │ └── WebConfig.java └── vo ├── BookingVO.java └── ResultVO.javaController 层只暴露 HTTP 接口返回一个统一的ResultVO。这种封装的好处是前端拿到的是固定格式的 JSON结构是{code, message, data}而不是某个实体类的原始字段。答辩时如果老师问“接口出错时前端怎么知道”你直接用这个类解释就行。VO 类和 Entity 类分开也是有意义的实体类不直接暴露给前端避免把数据库字段比如deleted这种逻辑删除标记传出去。2.3 配置文件的三个关键开关数据源、逻辑删除与 token 过期时间application.yml是本项目最先要改的文件。很多下载者拿到的配置里账号密码是root/123456数据库名是meeting_db。你本地如果不一样第一件事就是改这里。但有几个配置项的作用值得先搞清楚否则你改了也白改。spring: datasource: url: jdbc:mysql://localhost:3306/meeting_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: expire: 28800 secret: your-secret-key-change-itserverTimezoneAsia/Shanghai和jackson.time-zone是成对出现的。如果你的数据库和服务器时区不一致预约开始时间会莫名其妙差八小时这在后面第 5 章会详细讲。logic-delete-field: deleted表示所有实体类里的deleted字段都走逻辑删除执行 delete 时实际是 update查询时会自动追加deleted 0条件。jwt.expire单位是秒28800 就是 8 小时答辩演示中途如果 token 过期导致操作失败很尴尬一般我会建议调成 43200也就是 12 小时够撑一整天演示。3. 会议室预约核心流程建表、状态机与冲突检测的实现逻辑3.1 数据表设计五张表各管一段业务不搞大而全会议室预约系统的表数量不需要很多但每张表的职责必须清楚。常见的设计是五张表用户表、会议室表、预约记录表、审批记录表、锁定时间段表。预约记录表是核心其他表围绕它展开。表名作用核心字段关联关系sys_user用户与角色id、username、password、role、deleted预约记录的申请人meeting_room会议室基础信息id、name、location、capacity、status预约记录按 room_id 关联booking_record预约主记录id、room_id、user_id、start_time、end_time、status状态机核心表approve_record审批流水id、booking_id、approver_id、remark、result一对多关联预约记录room_lock会议室锁定id、room_id、lock_start、lock_end、reason用于维护或强制占用这里有个设计要点审批记录不要单独塞进 booking_record 的某个字段里而是拆成独立表。原因是审批可能有多轮比如管理员拒绝后申请人重新提交如果只留一个approve_remark字段历史记录就丢了。答辩时老师问“审批记录怎么追溯”这张表就是你的论据。room_lock表则用于处理会议室临时锁定的场景比如设备维修、领导临时征用它和预约记录互斥判断。3.2 预约状态机状态字段不是简单枚举而是一条流转规则booking_record.status字段是本系统的灵魂。直接存数字 0/1/2 也可以但建议存字符串代码里阅读性更强。状态有五档PENDING待审批、APPROVED已通过、REJECTED已拒绝、CANCELLED已取消、FINISHED已结束。状态流转要遵守规则只有PENDING状态可以被审批通过或拒绝只有PENDING和APPROVED状态可以被用户取消FINISHED是终态不再流转。这个规则最好写在 Service 层统一校验不要在 Controller 里散落判断。更安全的做法是做一个状态变更方法任何状态迁移都经过它。public BookingRecord changeStatus(Long recordId, String targetStatus, String operatorRole) { BookingRecord record bookingRecordMapper.selectById(recordId); if (record null) { throw new BusinessException(预约记录不存在); } String currentStatus record.getStatus(); // 只有合法迁移才放行 if (PENDING.equals(currentStatus) APPROVED.equals(targetStatus) ADMIN.equals(operatorRole)) { record.setStatus(APPROVED); } else if (PENDING.equals(currentStatus) REJECTED.equals(targetStatus)) { record.setStatus(REJECTED); } else if ((PENDING.equals(currentStatus) || APPROVED.equals(currentStatus)) CANCELLED.equals(targetStatus)) { record.setStatus(CANCELLED); } else { throw new BusinessException(非法的状态迁移 currentStatus - targetStatus); } bookingRecordMapper.updateById(record); return record; }这段代码把状态机集中在一处避免了不同接口里重复判断if/else导致逻辑不一致。参数operatorRole用来区分审批动作只能由管理员触发。这里的逻辑说明是状态机核心是“谁在什么状态下可以做什么”把规则收拢到一个方法里比到处散落状态判断更安全也更好解释。参数targetStatus用了字符串正式项目可以换成枚举但毕业设计阶段不必要反而徒增转换代码。3.3 冲突检测为什么不能只查已审批的记录这是答辩最容易问倒人的点。很多初版实现是预约时查一下该时间段是否已有APPROVED状态的记录有就返回冲突。这个逻辑有个漏洞两条PENDING状态的预约申请同时存在管理员先后都审批通过那会议室就被重复预订了。正确做法是冲突查询必须同时覆盖PENDING和APPROVED两种状态。public void checkConflict(Long roomId, LocalDateTime startTime, LocalDateTime endTime) { LambdaQueryWrapperBookingRecord wrapper Wrappers.lambdaQuery(); wrapper.eq(BookingRecord::getRoomId, roomId) .in(BookingRecord::getStatus, PENDING, APPROVED) .lt(BookingRecord::getStartTime, endTime) .gt(BookingRecord::getEndTime, startTime); Long count bookingRecordMapper.selectCount(wrapper); if (count 0) { throw new BusinessException(该会议室在此时间段已有预约申请或审批通过记录); } }这段查询的逻辑关键是区间重叠判断。判断两个时间段是否重叠不是判断“开始时间是否落在对方时间段内”而是使用开始时间 对方结束时间 AND 结束时间 对方开始时间。这个条件把所有重叠情况都覆盖了包括跨天预约和首尾相接。有人会疑惑那刚好一个结束、另一个开始算不算冲突按照上面的写法结束时间等于对方开始时间时不冲突这样设置是合理的因为交接场景下会议室可以连续使用。查询里带上deleted 0是 MyBatis-Plus 逻辑删除自动追加的不需要手写但要理解它的存在否则你排查时会觉得 SQL 多了一个没见过的条件。3.4 审批链路认领、审批与释放的完整实现审批动作发生前要确认记录处于PENDING状态审批通过后这条记录的时间段就正式占用。如果被拒绝申请人需要收到明确的原因。这看起来简单但有一个边界场景很容易漏会议室被锁定或者审批前会议室被删除了这时候再审批通过会导致数据不一致。Transactional(rollbackFor Exception.class) public void approveBooking(Long recordId, Long adminId, String remark) { BookingRecord record bookingRecordMapper.selectById(recordId); if (record null) { throw new BusinessException(预约记录不存在); } if (!PENDING.equals(record.getStatus())) { throw new BusinessException(只有待审批的记录才能被审批); } Room room roomMapper.selectById(record.getRoomId()); if (room null || room.getStatus() 0) { throw new BusinessException(会议室已不可用无法审批通过); } record.setStatus(APPROVED); record.setApproverId(adminId); record.setApproveTime(LocalDateTime.now()); bookingRecordMapper.updateById(record); ApproveRecord approveRecord new ApproveRecord(); approveRecord.setBookingId(recordId); approveRecord.setApproverId(adminId); approveRecord.setResult(APPROVED); approveRecord.setRemark(remark); approveRecordMapper.insert(approveRecord); }代码里最值得注意是Transactional(rollbackFor Exception.class)。默认情况下 Spring 事务只在遇到RuntimeException时回滚如果你的BusinessException继承自Exception而不是RuntimeException不设置rollbackFor会导致主记录更新了但审批流水没写进去而且不会报错非常隐蔽。毕业设计里这种“数据一半成功一半失败”的现象是最难查的。审批通过时同步插入审批流水相当于把状态变更留痕这也是答辩时展示你考虑周全的加分项。4. 后端 API 与时间校验把预约逻辑变成能调用的接口4.1 接口清单与权限对照这套系统的接口不多但每个角色的权限边界要清楚。管理员能管理会议室和审批预约普通用户只能预约和查看自己的记录。接口设计上建议按资源划分比如/api/room、/api/booking、/api/auth而不是把业务堆在十几个无意义的 URL 上。方法路径角色作用POST/api/auth/login所有人登录获取 tokenGET/api/room/list所有人查看会议室列表POST/api/room/addADMIN新增会议室POST/api/booking/createUSER提交预约申请POST/api/booking/approveADMIN审批预约GET/api/booking/mineUSER查看我的预约GET/api/booking/statsADMIN统计会议室使用率权限这块常见做法是写一个拦截器统一校验 token 和角色而不是在每个 Controller 方法里手写判断。Spring 的HandlerInterceptor里判断请求路径前缀比如/api/admin/**要求roleADMIN。这样做既省代码也能在一个地方回答“系统的权限控制是怎么做的”这个问题。4.2 一个完整的前后端交互例子从 HTTP 请求到业务落库以用户提交预约申请为例前端传 JSON 给/api/booking/create后端接收参数后做三步处理校验时间合法性、检测冲突、插入记录。下面这个 Controller 揭示了完整的调用链路。PostMapping(/api/booking/create) public ResultVO createBooking(RequestBody BookingCreateDTO dto, RequestAttribute(userId) Long userId) { // 前端传的是字符串格式的时间这里统一转成 LocalDateTime LocalDateTime startTime LocalDateTime.parse(dto.getStartTime(), DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss)); LocalDateTime endTime LocalDateTime.parse(dto.getEndTime(), DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss)); // 第一步基础校验 bookingService.validateTime(startTime, endTime); // 第二步冲突检测 bookingService.checkConflict(dto.getRoomId(), startTime, endTime); // 第三步插入预约记录 BookingRecord record new BookingRecord(); record.setRoomId(dto.getRoomId()); record.setUserId(userId); record.setStartTime(startTime); record.setEndTime(endTime); record.setStatus(PENDING); bookingService.create(record); return ResultVO.success(record.getId()); }这里的RequestAttribute(userId)来自前面说的拦截器。登录时解析 token把用户 ID 塞进 request 属性里业务方法里直接取省得每次从 token 里重新解析。BookingCreateDTO里的时间字段是字符串这在前端传 JSON 时很常见。这里有个值得说明的做法不要在 Controller 里做业务判断校验逻辑都放进 ServiceController 只做参数转换和结果封装。答辩时如果老师问“三层架构每层职责是什么”你可以直接用这段代码举例。4.3 时间参数校验后端必须拦下的三类非法请求时间校验是预约系统的高频 bug 来源。前端页面可能做了限制但接口可以被直接调用所以后端必须把三类非法请求挡在门外结束时间早于或等于开始时间、预约时间在过去、单次预约时长超限。public void validateTime(LocalDateTime startTime, LocalDateTime endTime) { if (startTime.isAfter(endTime) || startTime.isEqual(endTime)) { throw new BusinessException(结束时间必须晚于开始时间); } if (startTime.isBefore(LocalDateTime.now())) { throw new BusinessException(预约开始时间不能早于当前时间); } long hours Duration.between(startTime, endTime).toHours(); if (hours 24) { throw new BusinessException(单次预约时长不能超过24小时); } }参数说明Duration.between是 JDK 8 自带的时间差计算不需要额外依赖。toHours()返回的是整数时长想支持跨天预约就必须用LocalDateTime而不是拆分日期和时辰。最后一个校验“不超过 24 小时”适用于普通会议室场景如果系统里有长时预订需求这个阈值应该可配置而不是写死。我一般会建议把它放进application.yml里答辩时还能提一句“硬编码参数可配置化”这是加分项。5. 避坑指南跑通会议室预约系统最容易翻车的五个位置5.1 现象启动时数据库连接失败报Access denied for user rootlocalhost原因拿到压缩包后直接启动没改application.yml里的密码或者本地 MySQL 的 root 账号根本没设置密码。解决先确认本地 MySQL 能连上在命令行执行mysql -u root -p如果提示密码错误说明密码和配置不一致如果压根进不去 MySQL先重置 root 密码。常见做法是在 MySQL 8.0 下用ALTER USER rootlocalhost IDENTIFIED BY 123456;重置。不要纠结用不用 root毕业设计本地跑root 最省事。5.2 现象预约记录里的开始时间比实际点击时间晚了八小时原因MySQL 连接串里没加serverTimezoneAsia/Shanghai或者 jackson 的 time-zone 配置缺失。数据库把本地时间当成 UTC 存储显示时又按本地时区解析一来一回就差了八小时。解决在第 2.3 节的 yml 配置里把两个时区配置都补上改完后重启应用重新插入一条预约记录验证。还有另一种情况数据是正确入库的但前端展示不对那就是前端 JS 里的new Date()默认按浏览器时区解析的问题不关后端事。5.3 现象删除会议室报错提示外键约束失败原因meeting_room表被booking_record表外键引用物理删除会议室时预约记录还在引用它。解决要么层级删除先删预约记录再删会议室要么改成逻辑删除。本项目的 MyBatis-Plus 已经配置了逻辑删除所以正确操作是调用删除接口后会议室表的deleted字段被置为 1而不是真的 delete 掉。这一点要在答辩时说清楚数据是软删除保留历史记录保证审批记录可追溯。如果你删不掉多半是因为手动执行了 SQL 的物理 DELETE绕过应用层导致外键报错。5.4 现象日志里出现了 SQL 语句但数据库里的数据没变原因方法没有被Transactional标注或者事务没有正确提交。更隐蔽的是你在 Service 方法里捕获了异常但没抛出导致事务没触发回滚主数据却更新了部分字段。解决凡是涉及多张表写入的方法统一加Transactional(rollbackFor Exception.class)。Service 里的异常要么不捕获、交给上层处理要么捕获后重新抛出运行时异常否则事务管理器感知不到失败。5.5 现象前端请求接口一直返回 401 或 403原因拦截器里校验 token 的逻辑有问题。常见情况是登录接口本身被拦截器拦住了白名单路径没配置对前端永远拿不到 token。解决在 WebConfig 的拦截器注册处把/api/auth/login排除有条件地把预检请求 OPTIONS 也放行。前端如果启用了跨域后端必须配置CorsFilter否则浏览器发出的 OPTIONS 预检请求会直接挡在拦截器里后端日志还看不到任何错误。这是前后端联调里出现“请求没到达 Controller”的最常见原因。6. 答辩前自测三步把系统调到演示不翻车距离答辩还有两天时不要再看代码了做一次完整的自测。第一步用干净数据库启动系统把 SQL 脚本重新导入一遍确认没有任何残留脏数据。然后打开后端日志逐个调用登录、会议室列表、提交预约、管理员审批这四个接口每个都看返回值是否正常。切忌在演示现场才第一次跑完整流程环境变量、数据库密码、端口占用这些事提前十分钟都发现不了问题。第二步做一次人为制造的冲突用例。用同一账号或第二个账号提交两条时间重叠的预约申请验证第二条会被拒绝。再提交一条跨天预约比如 23:00 到次日 01:00确认系统能正确处理。这两条用例是答辩时最容易展示系统“智能化”的亮点也是老师大概率会追问的地方。如果冲突检测只覆盖了已审批状态这一步就会翻车。第三步检查 token 过期时间和系统时间格式。把jwt.expire临时改成 86400演示期间不要让它过期。时间显示格式统一用yyyy-MM-dd HH:mm:ss前端表格里如果出现2025-05-01T10:00:00这种带 T 的格式是某个接口返回了LocalDateTime默认序列化结果需要检查 jackson 配置是否生效。从那以后我每次拿到一个毕设资源包都会强制走一遍“空库启动-跑预约-提交冲突用例-审批全流程”这四步十分钟就能判断出这个包是真能用还是表面完整。很多看起来功能都有的系统全流程一跑就露馅不是这里缺个状态判断就是那里漏了事务注解。这个习惯帮我省下过大量深夜返工的精力希望你拿到资源后也先这么做一遍希望帮到你。本文还有配套的精品资源点击获取
Spring Boot+MyBatis-Plus会议室预约系统：核心流程与避坑指南
简介这是一套基于Java后端技术栈开发的智能化会议室预约管理系统完整项目面向计算机相关专业学生用于毕业设计或课程设计也适合希望掌握Spring Boot、MyBatis等主流框架的Java后端初学者。系统涵盖用户管理、会议室管理、预约管理、日程管理、提醒服务及系统设置等模块展示了从需求分析到编码实现、单元测试的完整开发流程。压缩包共613个文件包含92个Java源码、37个JSP页面、119个class编译文件、62个jar依赖库及51个CSS样式另含大量图片素材整体约47.64MB。目前已有95人学习下载适合作为理解企业级MVC架构、数据库设计与前后端交互的实战参考。通过阅读项目源码和配置读者可掌握Spring Boot整合MyBatis与Thymeleaf的具体实现方式学习时间冲突检测、权限控制等业务场景的编码技巧为独立完成类似系统开发提供直接借鉴。1. 智能化会议室预约管理系统不是交差而是能自己讲清楚的整套 Java 后端五月份是毕业设计答辩的高峰很多 Java 方向的同学下载到的所谓“毕设源码”要么是十几年前的 SSH 古董要么是前后端代码混成一团、启动三分钟就报错。这套智能化会议室预约管理系统是另外一类Spring Boot 做后端骨架MyBatis-Plus 操作数据库流程上把预约、冲突检测、审批、统计一条链走完。换句话说它不是只给你一个能截图的页面而是让答辩现场能讲出“系统怎么处理两个人同时抢一间会议室”这种核心问题。适合正在做毕业设计或课程设计、后端基础一般、需要能跑通又能讲原理的人。2. 项目结构与技术栈先看清 Spring Boot 集成 MyBatis-Plus 是怎么组织的2.1 资源包里有什么一份可以落地的 Maven 工程拿到压缩包后先别急着启动。先看根目录下的结构确认它是标准 Maven 工程而不是散件拼凑。一个合格的资源包至少应该包含后端的 Java 源码、SQL 初始化脚本、以及一份启动说明。本项目采用的是 Spring Boot 2.x 配合 MyBatis-Plus数据库是 MySQL 8.0。选择这三样组合的原因很直接Spring Boot 解决配置地狱MyBatis-Plus 解决手写大量 XML 的重复劳动MySQL 则在校园环境和答辩演示时最容易找到运行环境。依赖层面pom.xml 里除了 spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java还有一个很关键的 lombok。很多新手第一次编译失败就出在 lombok 上IDE 没装插件会导致实体类的 getter/setter 报错。建议在 IDEA 里打开 Settings确认 Annotation Processing 勾选了 Enable annotation processing。这是最常见的“代码没问题但编译不过”的坑。数据访问层选 MyBatis-Plus 而不是原生 MyBatis还有个实际好处分页插件、逻辑删除、自动填充时间都是内置的表结构设计得不太离谱的话基础 CRUD 可以不写一行 SQL。这对毕业设计来说意味着能把精力放在业务规则上比如冲突检测、审批流转而不是在 BaseMapper 里反复复制粘贴简单查询。2.2 后端分层目录从包名看懂这套系统的分层方式打开src/main/java下的包结构一般会按controller/service/mapper/entity/config/vo来分。这种分层不是毕业设计默认格式而是能直接回答答辩问题的结构。Controller 只做参数接收和结果封装Service 写业务规则Mapper 层只负责数据库交互Entity 对应表。如果你发现某个包里的类职责乱了比如 Service 里直接拼 SQL那后面排错时你会非常痛苦。com.school.meeting ├── controller │ ├── AuthController.java │ ├── RoomController.java │ └── BookingController.java ├── service │ ├── BookingService.java │ └── RoomService.java ├── mapper │ ├── UserMapper.java │ ├── RoomMapper.java │ └── BookingRecordMapper.java ├── entity │ ├── User.java │ ├── Room.java │ └── BookingRecord.java ├── config │ ├── MybatisPlusConfig.java │ └── WebConfig.java └── vo ├── BookingVO.java └── ResultVO.javaController 层只暴露 HTTP 接口返回一个统一的ResultVO。这种封装的好处是前端拿到的是固定格式的 JSON结构是{code, message, data}而不是某个实体类的原始字段。答辩时如果老师问“接口出错时前端怎么知道”你直接用这个类解释就行。VO 类和 Entity 类分开也是有意义的实体类不直接暴露给前端避免把数据库字段比如deleted这种逻辑删除标记传出去。2.3 配置文件的三个关键开关数据源、逻辑删除与 token 过期时间application.yml是本项目最先要改的文件。很多下载者拿到的配置里账号密码是root/123456数据库名是meeting_db。你本地如果不一样第一件事就是改这里。但有几个配置项的作用值得先搞清楚否则你改了也白改。spring: datasource: url: jdbc:mysql://localhost:3306/meeting_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: expire: 28800 secret: your-secret-key-change-itserverTimezoneAsia/Shanghai和jackson.time-zone是成对出现的。如果你的数据库和服务器时区不一致预约开始时间会莫名其妙差八小时这在后面第 5 章会详细讲。logic-delete-field: deleted表示所有实体类里的deleted字段都走逻辑删除执行 delete 时实际是 update查询时会自动追加deleted 0条件。jwt.expire单位是秒28800 就是 8 小时答辩演示中途如果 token 过期导致操作失败很尴尬一般我会建议调成 43200也就是 12 小时够撑一整天演示。3. 会议室预约核心流程建表、状态机与冲突检测的实现逻辑3.1 数据表设计五张表各管一段业务不搞大而全会议室预约系统的表数量不需要很多但每张表的职责必须清楚。常见的设计是五张表用户表、会议室表、预约记录表、审批记录表、锁定时间段表。预约记录表是核心其他表围绕它展开。表名作用核心字段关联关系sys_user用户与角色id、username、password、role、deleted预约记录的申请人meeting_room会议室基础信息id、name、location、capacity、status预约记录按 room_id 关联booking_record预约主记录id、room_id、user_id、start_time、end_time、status状态机核心表approve_record审批流水id、booking_id、approver_id、remark、result一对多关联预约记录room_lock会议室锁定id、room_id、lock_start、lock_end、reason用于维护或强制占用这里有个设计要点审批记录不要单独塞进 booking_record 的某个字段里而是拆成独立表。原因是审批可能有多轮比如管理员拒绝后申请人重新提交如果只留一个approve_remark字段历史记录就丢了。答辩时老师问“审批记录怎么追溯”这张表就是你的论据。room_lock表则用于处理会议室临时锁定的场景比如设备维修、领导临时征用它和预约记录互斥判断。3.2 预约状态机状态字段不是简单枚举而是一条流转规则booking_record.status字段是本系统的灵魂。直接存数字 0/1/2 也可以但建议存字符串代码里阅读性更强。状态有五档PENDING待审批、APPROVED已通过、REJECTED已拒绝、CANCELLED已取消、FINISHED已结束。状态流转要遵守规则只有PENDING状态可以被审批通过或拒绝只有PENDING和APPROVED状态可以被用户取消FINISHED是终态不再流转。这个规则最好写在 Service 层统一校验不要在 Controller 里散落判断。更安全的做法是做一个状态变更方法任何状态迁移都经过它。public BookingRecord changeStatus(Long recordId, String targetStatus, String operatorRole) { BookingRecord record bookingRecordMapper.selectById(recordId); if (record null) { throw new BusinessException(预约记录不存在); } String currentStatus record.getStatus(); // 只有合法迁移才放行 if (PENDING.equals(currentStatus) APPROVED.equals(targetStatus) ADMIN.equals(operatorRole)) { record.setStatus(APPROVED); } else if (PENDING.equals(currentStatus) REJECTED.equals(targetStatus)) { record.setStatus(REJECTED); } else if ((PENDING.equals(currentStatus) || APPROVED.equals(currentStatus)) CANCELLED.equals(targetStatus)) { record.setStatus(CANCELLED); } else { throw new BusinessException(非法的状态迁移 currentStatus - targetStatus); } bookingRecordMapper.updateById(record); return record; }这段代码把状态机集中在一处避免了不同接口里重复判断if/else导致逻辑不一致。参数operatorRole用来区分审批动作只能由管理员触发。这里的逻辑说明是状态机核心是“谁在什么状态下可以做什么”把规则收拢到一个方法里比到处散落状态判断更安全也更好解释。参数targetStatus用了字符串正式项目可以换成枚举但毕业设计阶段不必要反而徒增转换代码。3.3 冲突检测为什么不能只查已审批的记录这是答辩最容易问倒人的点。很多初版实现是预约时查一下该时间段是否已有APPROVED状态的记录有就返回冲突。这个逻辑有个漏洞两条PENDING状态的预约申请同时存在管理员先后都审批通过那会议室就被重复预订了。正确做法是冲突查询必须同时覆盖PENDING和APPROVED两种状态。public void checkConflict(Long roomId, LocalDateTime startTime, LocalDateTime endTime) { LambdaQueryWrapperBookingRecord wrapper Wrappers.lambdaQuery(); wrapper.eq(BookingRecord::getRoomId, roomId) .in(BookingRecord::getStatus, PENDING, APPROVED) .lt(BookingRecord::getStartTime, endTime) .gt(BookingRecord::getEndTime, startTime); Long count bookingRecordMapper.selectCount(wrapper); if (count 0) { throw new BusinessException(该会议室在此时间段已有预约申请或审批通过记录); } }这段查询的逻辑关键是区间重叠判断。判断两个时间段是否重叠不是判断“开始时间是否落在对方时间段内”而是使用开始时间 对方结束时间 AND 结束时间 对方开始时间。这个条件把所有重叠情况都覆盖了包括跨天预约和首尾相接。有人会疑惑那刚好一个结束、另一个开始算不算冲突按照上面的写法结束时间等于对方开始时间时不冲突这样设置是合理的因为交接场景下会议室可以连续使用。查询里带上deleted 0是 MyBatis-Plus 逻辑删除自动追加的不需要手写但要理解它的存在否则你排查时会觉得 SQL 多了一个没见过的条件。3.4 审批链路认领、审批与释放的完整实现审批动作发生前要确认记录处于PENDING状态审批通过后这条记录的时间段就正式占用。如果被拒绝申请人需要收到明确的原因。这看起来简单但有一个边界场景很容易漏会议室被锁定或者审批前会议室被删除了这时候再审批通过会导致数据不一致。Transactional(rollbackFor Exception.class) public void approveBooking(Long recordId, Long adminId, String remark) { BookingRecord record bookingRecordMapper.selectById(recordId); if (record null) { throw new BusinessException(预约记录不存在); } if (!PENDING.equals(record.getStatus())) { throw new BusinessException(只有待审批的记录才能被审批); } Room room roomMapper.selectById(record.getRoomId()); if (room null || room.getStatus() 0) { throw new BusinessException(会议室已不可用无法审批通过); } record.setStatus(APPROVED); record.setApproverId(adminId); record.setApproveTime(LocalDateTime.now()); bookingRecordMapper.updateById(record); ApproveRecord approveRecord new ApproveRecord(); approveRecord.setBookingId(recordId); approveRecord.setApproverId(adminId); approveRecord.setResult(APPROVED); approveRecord.setRemark(remark); approveRecordMapper.insert(approveRecord); }代码里最值得注意是Transactional(rollbackFor Exception.class)。默认情况下 Spring 事务只在遇到RuntimeException时回滚如果你的BusinessException继承自Exception而不是RuntimeException不设置rollbackFor会导致主记录更新了但审批流水没写进去而且不会报错非常隐蔽。毕业设计里这种“数据一半成功一半失败”的现象是最难查的。审批通过时同步插入审批流水相当于把状态变更留痕这也是答辩时展示你考虑周全的加分项。4. 后端 API 与时间校验把预约逻辑变成能调用的接口4.1 接口清单与权限对照这套系统的接口不多但每个角色的权限边界要清楚。管理员能管理会议室和审批预约普通用户只能预约和查看自己的记录。接口设计上建议按资源划分比如/api/room、/api/booking、/api/auth而不是把业务堆在十几个无意义的 URL 上。方法路径角色作用POST/api/auth/login所有人登录获取 tokenGET/api/room/list所有人查看会议室列表POST/api/room/addADMIN新增会议室POST/api/booking/createUSER提交预约申请POST/api/booking/approveADMIN审批预约GET/api/booking/mineUSER查看我的预约GET/api/booking/statsADMIN统计会议室使用率权限这块常见做法是写一个拦截器统一校验 token 和角色而不是在每个 Controller 方法里手写判断。Spring 的HandlerInterceptor里判断请求路径前缀比如/api/admin/**要求roleADMIN。这样做既省代码也能在一个地方回答“系统的权限控制是怎么做的”这个问题。4.2 一个完整的前后端交互例子从 HTTP 请求到业务落库以用户提交预约申请为例前端传 JSON 给/api/booking/create后端接收参数后做三步处理校验时间合法性、检测冲突、插入记录。下面这个 Controller 揭示了完整的调用链路。PostMapping(/api/booking/create) public ResultVO createBooking(RequestBody BookingCreateDTO dto, RequestAttribute(userId) Long userId) { // 前端传的是字符串格式的时间这里统一转成 LocalDateTime LocalDateTime startTime LocalDateTime.parse(dto.getStartTime(), DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss)); LocalDateTime endTime LocalDateTime.parse(dto.getEndTime(), DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss)); // 第一步基础校验 bookingService.validateTime(startTime, endTime); // 第二步冲突检测 bookingService.checkConflict(dto.getRoomId(), startTime, endTime); // 第三步插入预约记录 BookingRecord record new BookingRecord(); record.setRoomId(dto.getRoomId()); record.setUserId(userId); record.setStartTime(startTime); record.setEndTime(endTime); record.setStatus(PENDING); bookingService.create(record); return ResultVO.success(record.getId()); }这里的RequestAttribute(userId)来自前面说的拦截器。登录时解析 token把用户 ID 塞进 request 属性里业务方法里直接取省得每次从 token 里重新解析。BookingCreateDTO里的时间字段是字符串这在前端传 JSON 时很常见。这里有个值得说明的做法不要在 Controller 里做业务判断校验逻辑都放进 ServiceController 只做参数转换和结果封装。答辩时如果老师问“三层架构每层职责是什么”你可以直接用这段代码举例。4.3 时间参数校验后端必须拦下的三类非法请求时间校验是预约系统的高频 bug 来源。前端页面可能做了限制但接口可以被直接调用所以后端必须把三类非法请求挡在门外结束时间早于或等于开始时间、预约时间在过去、单次预约时长超限。public void validateTime(LocalDateTime startTime, LocalDateTime endTime) { if (startTime.isAfter(endTime) || startTime.isEqual(endTime)) { throw new BusinessException(结束时间必须晚于开始时间); } if (startTime.isBefore(LocalDateTime.now())) { throw new BusinessException(预约开始时间不能早于当前时间); } long hours Duration.between(startTime, endTime).toHours(); if (hours 24) { throw new BusinessException(单次预约时长不能超过24小时); } }参数说明Duration.between是 JDK 8 自带的时间差计算不需要额外依赖。toHours()返回的是整数时长想支持跨天预约就必须用LocalDateTime而不是拆分日期和时辰。最后一个校验“不超过 24 小时”适用于普通会议室场景如果系统里有长时预订需求这个阈值应该可配置而不是写死。我一般会建议把它放进application.yml里答辩时还能提一句“硬编码参数可配置化”这是加分项。5. 避坑指南跑通会议室预约系统最容易翻车的五个位置5.1 现象启动时数据库连接失败报Access denied for user rootlocalhost原因拿到压缩包后直接启动没改application.yml里的密码或者本地 MySQL 的 root 账号根本没设置密码。解决先确认本地 MySQL 能连上在命令行执行mysql -u root -p如果提示密码错误说明密码和配置不一致如果压根进不去 MySQL先重置 root 密码。常见做法是在 MySQL 8.0 下用ALTER USER rootlocalhost IDENTIFIED BY 123456;重置。不要纠结用不用 root毕业设计本地跑root 最省事。5.2 现象预约记录里的开始时间比实际点击时间晚了八小时原因MySQL 连接串里没加serverTimezoneAsia/Shanghai或者 jackson 的 time-zone 配置缺失。数据库把本地时间当成 UTC 存储显示时又按本地时区解析一来一回就差了八小时。解决在第 2.3 节的 yml 配置里把两个时区配置都补上改完后重启应用重新插入一条预约记录验证。还有另一种情况数据是正确入库的但前端展示不对那就是前端 JS 里的new Date()默认按浏览器时区解析的问题不关后端事。5.3 现象删除会议室报错提示外键约束失败原因meeting_room表被booking_record表外键引用物理删除会议室时预约记录还在引用它。解决要么层级删除先删预约记录再删会议室要么改成逻辑删除。本项目的 MyBatis-Plus 已经配置了逻辑删除所以正确操作是调用删除接口后会议室表的deleted字段被置为 1而不是真的 delete 掉。这一点要在答辩时说清楚数据是软删除保留历史记录保证审批记录可追溯。如果你删不掉多半是因为手动执行了 SQL 的物理 DELETE绕过应用层导致外键报错。5.4 现象日志里出现了 SQL 语句但数据库里的数据没变原因方法没有被Transactional标注或者事务没有正确提交。更隐蔽的是你在 Service 方法里捕获了异常但没抛出导致事务没触发回滚主数据却更新了部分字段。解决凡是涉及多张表写入的方法统一加Transactional(rollbackFor Exception.class)。Service 里的异常要么不捕获、交给上层处理要么捕获后重新抛出运行时异常否则事务管理器感知不到失败。5.5 现象前端请求接口一直返回 401 或 403原因拦截器里校验 token 的逻辑有问题。常见情况是登录接口本身被拦截器拦住了白名单路径没配置对前端永远拿不到 token。解决在 WebConfig 的拦截器注册处把/api/auth/login排除有条件地把预检请求 OPTIONS 也放行。前端如果启用了跨域后端必须配置CorsFilter否则浏览器发出的 OPTIONS 预检请求会直接挡在拦截器里后端日志还看不到任何错误。这是前后端联调里出现“请求没到达 Controller”的最常见原因。6. 答辩前自测三步把系统调到演示不翻车距离答辩还有两天时不要再看代码了做一次完整的自测。第一步用干净数据库启动系统把 SQL 脚本重新导入一遍确认没有任何残留脏数据。然后打开后端日志逐个调用登录、会议室列表、提交预约、管理员审批这四个接口每个都看返回值是否正常。切忌在演示现场才第一次跑完整流程环境变量、数据库密码、端口占用这些事提前十分钟都发现不了问题。第二步做一次人为制造的冲突用例。用同一账号或第二个账号提交两条时间重叠的预约申请验证第二条会被拒绝。再提交一条跨天预约比如 23:00 到次日 01:00确认系统能正确处理。这两条用例是答辩时最容易展示系统“智能化”的亮点也是老师大概率会追问的地方。如果冲突检测只覆盖了已审批状态这一步就会翻车。第三步检查 token 过期时间和系统时间格式。把jwt.expire临时改成 86400演示期间不要让它过期。时间显示格式统一用yyyy-MM-dd HH:mm:ss前端表格里如果出现2025-05-01T10:00:00这种带 T 的格式是某个接口返回了LocalDateTime默认序列化结果需要检查 jackson 配置是否生效。从那以后我每次拿到一个毕设资源包都会强制走一遍“空库启动-跑预约-提交冲突用例-审批全流程”这四步十分钟就能判断出这个包是真能用还是表面完整。很多看起来功能都有的系统全流程一跑就露馅不是这里缺个状态判断就是那里漏了事务注解。这个习惯帮我省下过大量深夜返工的精力希望你拿到资源后也先这么做一遍希望帮到你。本文还有配套的精品资源点击获取