会议室预约这件事我在企业里见得太多了。行政在微信群里发Excel表格大家接龙填时间或者墙上贴一张纸质排期表谁要用就先来登记结果经常出现两个部门同时约同一个会议室到了现场才发现撞了。做了这么多年管理系统我越来越觉得这类“看起来简单”的预约系统真正做好很考验对业务的理解。SpringBootVue这个技术栈在会议室预约管理系统里用得非常多也特别适合作为计算机毕业设计的选题——业务流程清晰、技术栈主流、前后端分离的架构还能体现完整的工程能力。这篇就基于一个我实际带过的毕设项目来聊从需求拆解、数据库设计、核心代码到踩坑实录把整个系统的关键细节全部讲透。这个项目解决的核心问题很实在企业会议室和活动场地的信息不透明、预订冲突率高、审批流程混乱、使用率无法统计。系统做出来之后员工能在线查看所有场地的空闲状态、按需下单预订管理员可以审批、管理房间、统计使用情况整个流程全部线上闭环。如果你正在准备毕设或者刚入行想找一个前后端分离的完整实战项目练手这篇内容应该能帮你省掉不少查资料的功夫。1. 项目整体设计与技术选型思路1.1 一个会议预约系统要解决的核心矛盾动手写代码之前我习惯先搞清楚一个问题这个系统到底在解决什么矛盾会议室管理的本质矛盾是“资源有限、需求随机、信息分散”。资源有限是指一个公司会议室数量固定尤其是大会议室和带投屏设备的会议室更是稀缺资源需求随机是指员工开会时间不固定经常有临时会议、客户到访需要临时订房信息分散是指如果没有统一的系统会议室占用情况只存在于某个人的脑子里或者某个Excel文件里别人根本看不到。这三个痛点叠在一起就推导出了系统必须满足的四项核心能力可见性所有场地状态在系统内实时可查排他性同一时间一个场地只能被一个预订占用可追溯性谁在什么时间订了哪个会议室历史记录清晰可查可分析性能统计出场地的使用率、高峰时段为行政优化资源配置提供数据支撑。我看过很多毕设版本的会议室系统功能罗列得挺多但很多都忽略了排他性和可分析性这两个核心点导致做出来像个玩具。比如有的系统预订时不查冲突管理员手动协调这就是没抓住矛盾本质。所以真正动手设计之前先把这四个核心能力想清楚后面每写一个功能都能对得上号。1.2 为什么选SpringBootVue而不是其他组合技术选型这部分每年都有同学问我学长用SSH行不行用JSP加Servlet行不行或者干脆做个纯前端行不行先说结论SpringBootVue是目前最适合做这类管理系统的组合没有之一。分析一下各方案的利弊就明白了。SSHStrutsSpringHibernate是十年前的技术配置繁琐得让人崩溃现在市面上大部分公司早就不用了拿它做毕设不仅自己写得痛苦答辩老师看到技术栈也会觉得过时。JSPServlet虽然能跑但前后端耦合在一起页面逻辑混乱改一个按钮要找半天代码而且没法体现“前后端分离”这个现代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字段名类型说明idbigint主键自增usernamevarchar(50)登录名唯一passwordvarchar(100)BCrypt加密后的密码real_namevarchar(50)真实姓名phonevarchar(20)联系电话roletinyint角色0普通用户1管理员statustinyint状态0正常1禁用create_timedatetime创建时间deletedtinyint逻辑删除标记user表设计要点是role字段要放在用户表里而不是单独建角色表因为系统只有两类角色单独建表属于过度设计对于毕设来说反而增加了没必要的关联查询复杂度。password字段必须用BCrypt加密存储千万不能明文保存这点答辩时经常被问到。场地表meeting_room字段名类型说明idbigint主键自增room_namevarchar(100)场地名称room_typetinyint场地类型1会议室2培训室3活动室locationvarchar(200)所在位置如“A栋3楼301”capacityint可容纳人数equipmentvarchar(500)设备清单逗号分隔如“投影仪,视频会议,白板”picturevarchar(500)图片URLstatustinyint状态0可用1禁用create_timedatetime创建时间deletedtinyint逻辑删除标记equipment字段用逗号分隔的字符串来存很多同学喜欢单独建一张设备表然后做多对多关联但实际使用中设备信息只是用来展示根本不需要单独查询设备维度字符串存储已经足够了。预订表reservation字段名类型说明idbigint主键自增user_idbigint预订人IDroom_idbigint场地IDmeeting_namevarchar(200)会议/活动主题start_timedatetime开始时间end_timedatetime结束时间statustinyint状态0待审核1已通过2已驳回3已取消4已完成remarkvarchar(500)备注audit_user_idbigint审核人IDaudit_timedatetime审核时间create_timedatetime创建时间deletedtinyint逻辑删除标记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 groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version4.4.0/version /dependency dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.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) { LambdaQueryWrapperSysUser 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就搞定避免N1查询问题。时间轴功能更有意思。用户选中某一天后前端展示从早上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. 冲突检测 LambdaQueryWrapperReservation 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.urljdbc:mysql://localhost:3306/meeting_room?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/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节点可能会卡顿。有两个低成本高收益的优化手段。一个是懒加载图片。场地图片用loadinglazy属性或者用VueLazyload插件页面滚动到对应位置时才加载图片首屏加载速度会明显提升。另一个是合理使用Vue的computed和watch的边界。不要在watch里做深度拷贝和复杂运算数据提取逻辑放到computed里Vue会对computed做缓存只有依赖项变化时才重新计算。这个细节面试也常问值得好好理解。写在最后的一个建议做这个项目的时候我最大的感受是真正的难点从来不是写代码而是把业务流程想清楚的那一周。你花三天把数据库表和状态机设计得明明白白后面的编码就是体力活反过来脑子一热直接开写中途返工的成本往往是预期的两倍以上。我自己做的时候最满意的不是代码本身而是把“审批状态机”和“冲突检测”这两个核心逻辑真正想透了。后来出去面试面试官问这类业务系统的设计思路我都能从这两个点切入交流起来非常顺畅。你也值得把这个项目当成一次真实的工程训练而不是仅仅当成一个要交差的作业。