这套会议室预约管理系统是我在辅导毕业设计时经常推荐的一个经典选题。它不涉及复杂的算法却覆盖了Web开发里最核心的那套东西用户登录、权限控制、增删改查、时间冲突检测、状态流转前端交互与后端接口的配合也足够完整。如果你正在发愁毕设选什么题目或者拿到了一套源码想快速吃透并改成自己的项目这篇内容可以直接帮你把整条链路打通。我见过太多同学在选题上栽跟头要么选了“智能推荐系统”这种算法难度过高的要么选了“图书管理”这种做得太烂大街的。会议室预约管理系统属于典型的“中间档位”——别人一听就觉得你有实际场景答辩时能讲清楚业务逻辑代码量也足够撑起一篇像样的论文。最关键的是它自带一个很自然的业务痛点会议室资源是有限的怎么合理分配、怎么避免预约冲突、怎么提升使用效率这些都可以在论文里展开写。下面我按自己做项目管理时的思路从设计到实现再到部署和维护把整个系统的关键环节拆开讲一遍。无论你是打算直接用这份源码交差还是想深入改造这篇文章都能给你省不少时间。1. 项目概述与毕设选型思路1.1 这个系统到底解决了什么问题先想明白一件事会议室预约系统本质上是做“资源调度”。企业或学校里的会议室数量有限不同部门、不同时间段都有使用需求如果没有一套统一管理机制就会出现三种典型乱象一是“撞车”两个部门同时预定了同一间会议室到了现场才发现时间重叠只能临时协调二是“占而不约”有人长期把某间会议室当办公室用别人想用却进不去资源利用率极低三是“约而不用”预约了但临时取消或干脆没到场也没有系统记录来约束。这套系统要解决的就是通过线上化流程把“预约—审批—使用—反馈”这条链路管理起来。用户能实时看到哪些会议室在哪个时间段空闲提交预约后系统自动检测冲突管理员和审批者能掌握所有预约记录超时未签到或未取消的预约可以自动释放。这样一来资源使用有迹可循房间利用率能显著提高。1.2 为什么这个题目特别适合做毕设我在辅导毕设这几年越来越觉得选题决定了毕业设计的成败。会议室预约管理系统这个题目有几个天然优势第一业务场景非常清晰。任何人都有预约会议室的经历甚至不需要额外调研就能理解需求这降低了答辩时讲不清楚业务的风险。第二功能模块伸缩性极强。基本功能够你写用户管理、会议室管理、预约管理、审批管理。想做得深入一些可以加消息通知、签到退签、数据统计、用户信用积分甚至可以结合小程序或企业微信做移动端。写到论文里每一块都能对应一章内容天然饱满。第三技术栈选择自由。后端你可以用Spring Boot MyBatis也可以用Python的Django或Flask甚至Node.js前端可以Vue、React、Element UI也可以做传统JSP页面。这意味着你可以挑自己最熟悉的技术来写实现门槛降到最低。第四系统是“小而全”的典型。它包含了Web开发中最常见的操作——分页查询、条件筛选、表单提交、状态变更、权限控制这些你做一遍比刷十遍教程都管用。2. 技术栈选择与项目架构搭建2.1 后端技术选型为什么我推荐Spring Boot拿到这份源码后你会发现它用的技术组合非常“主流”Spring Boot MyBatis Plus MySQL前端搭配Vue 3 Element Plus。这套组合在你查资料、找解决方案时最方便社区生态也最完善。Spring Boot这几年已经成为Java后端开发的默认选项原因不难理解。它采用“约定大于配置”的思路把以往Spring MVC项目里繁琐的XML配置全部用自动配置替代。你只需要在pom.xml里引入依赖加上对应的yml配置一个可运行的Web应用就搭起来了。比如启动类只有几行代码不想玩转的注解体系也能跑通一个最简单的“Hello World”接口。MyBatis Plus的价值则体现在“懒人福利”上。它内置了通用Mapper单表的增删改查基本不用写SQL直接调用selectById、selectPage、insert这些方法就能完成。对于会议上业务这种以单表操作为主的系统效率提升非常明显。当然我建议你还是把底层SQL搞清楚因为答辩时老师最喜欢问“你这么写的SQL是什么逻辑”。MySQL作为存储层没什么好说的这里只提醒一点如果你的环境安装的是MySQL 8.x要注意驱动版本必须匹配。很多同学项目跑不起来就是因为用了mysql-connector-java 5.x的老驱动去连MySQL 8报错“Unable to load authentication plugin”换成com.mysql.cj.jdbc.Driver就能解决。2.2 前端环境准备与初始化前端部分源码大概率是基于Vue 3 Element Plus的管理后台模板改造的。拿到代码后的第一件事不是急着运行而是先确认Node.js版本。Vue 3和Vite构建工具要求Node版本不低于14.18推荐直接用16以上避免版本过低导致依赖安装失败。环境准备好以后进入前端目录执行npm install npm run dev如果一切正常命令行会输出一串提示访问http://localhost:5173就能看到登录页。这里有一个高频坑很多同学安装了依赖却报“You are running Vue in development mode”那只是开发模式的正常提示不用慌真正需要关注的是后端接口是否能通。后端项目一般用Maven管理依赖在IDEA里选择File - Open找到后端的pom.xml等Maven把依赖下载完。启动前需要修改application.yml里的数据库连接信息把用户名和密码改成自己本地的。我在第一次跑通这个项目时花了半小时排查一个极其低级的错误忘记在application.yml里把数据库名改成代码里用的名字导致启动后报表不存在的异常。2.3 项目整体目录结构与分层思想拿到源码先别急着运行先花十分钟把项目结构浏览一遍。优秀的项目一定是分层的这样不仅看起来舒服改起来也方便答辩时老师会更认可。我建议你用这个思路去审视代码结构controller包负责接收HTTP请求把参数交给service层处理最后返回结果给前端。这个包里的类命名一般以Controller结尾比如BookingController、MeetingRoomController。service接口与service.impl实现包业务逻辑的核心。比如“预约时检查时间冲突”这段逻辑就应该写在service里而不是塞在controller里。mapper包数据访问层负责与数据库交互。继承BaseMapper后直接获得单表CRUD能力。entity包数据库实体类字段与表结构一一对应。config包放配置类比如跨域配置、拦截器配置、MyBatis Plus分页插件配置等。common或utils包放通用返回结构、异常处理类、工具类。分层设计最直观的好处是当你需要排查问题时可以按“请求从controller进来到service做业务判断再到mapper操作数据”这条链路去追踪。这也是我在排查Bug时最喜欢用的方式。3. 数据库设计与核心表结构3.1 核心数据表清单与字段设计会议室预约系统的数据库表一般不会少于五张用户表、会议室表、预约记录表、审批记录表、通知消息表。下面我把每张表的关键字段列出来并解释字段设计的理由。用户表sys_user常用字段包括id、username、password、real_name、email、phone、role区分管理员和普通用户、department所属部门、status是否禁用。要注意密码最好不要明文存储现实中至少用MD5讲究一点就用BCrypt。群里不少同学图省事直接把明文存进去答辩时老师一问“密码安全性怎么考虑”立刻就卡住了。会议室表meeting_room字段包括id、room_name、location所在楼层或位置、capacity容纳人数、equipment投影、白板、视频设备等、status启用/停用、description。这里我建议增加一个room_type字段区分普通会议室、培训室、报告厅等这样筛选时前端能多一个下拉选项功能看着更丰富。预约记录表booking_record是系统中最关键的表。字段包括id、user_id、room_id、book_date预约日期、start_time开始时段、end_time结束时段、title会议主题、participants参会人数、status待审批、已通过、已拒绝、已取消、已完成、create_time、approve_user_id、approve_time、remark备注。3.2 为什么预约时间段用“日期 开始时间 结束时间”存储这里我想展开说一个数据库设计时的决策点预约时间段到底怎么存常见的方案有两种。第一种是“跨天毫秒级时间戳”存start_time和end_time两个datetime字段好处是精确到秒计算时长直接相减坏处是显示时需要考虑时区跨天预约比如晚上23点到第二天凌晨1点处理起来更麻烦。第二种是设计成“日期 时间段编号”或“日期 开始时间 结束时间”。本系统采用的是“日期 时间点”的组合。比如预约2025-06-10上午9点到11点存的是book_date 2025-06-10、start_time 09:00、end_time 11:00。这种设计更贴近会议室预约的盘点习惯系统只提供固定的时间片段比如以半小时为单位用户选取开始和结束时间然后预约记录与book_date关联。它的好处是肉眼可读性好写SQL检测冲突时直接在“日期相等 时间范围重叠”两个条件上过滤即可逻辑清晰不容易出错。如果你想让系统支持跨天预约就需要在前端把时间选择器设置成允许跨天同时后端要加上日期偏移的判断。但说实话大多数场景根本不需要我在设计时直接把跨天预约禁掉省去了一大堆边界问题。3.3 一条标准的建表SQL长什么样为了避免你在导入源码自带SQL时踩坑我贴一段典型建表语句。注意字段注释要写清楚外键逻辑用“逻辑外键”而不是真正的FOREIGN KEY约束这样后期清理数据更灵活。CREATE TABLE booking_record ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint DEFAULT NULL COMMENT 预约人ID, room_id bigint DEFAULT NULL COMMENT 会议室ID, book_date date DEFAULT NULL COMMENT 使用日期, start_time varchar(10) DEFAULT NULL COMMENT 开始时间 HH:mm, end_time varchar(10) DEFAULT NULL COMMENT 结束时间 HH:mm, title varchar(100) DEFAULT NULL COMMENT 会议主题, participants int DEFAULT NULL COMMENT 参会人数, status tinyint DEFAULT 0 COMMENT 0待审批 1已通过 2已拒绝 3已取消 4已完成, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_room_date (room_id, book_date), KEY idx_user (user_id) ) ENGINEInnoDB AUTO_INCREMENT0 DEFAULT CHARSETutf8mb4 COMMENT会议室预约记录表;注意我建了两个索引idx_room_date用于联合查询某会议室某天是否被预约也就是冲突检测的核心场景idx_user用于查询“我预约了哪些会议室”。索引不是越多越好这两个已经覆盖了绝大多数业务查询。4. 核心业务逻辑实现预约流程与冲突检测4.1 预约流程的状态机设计预约记录有一个非常重要的属性状态。它的流转可以看作一台简单的状态机用户提交预约 → 状态为“待审批”0管理员/审批人通过 → 状态为“已通过”1管理员/审批人拒绝 → 状态为“已拒绝”2用户取消预约 → 状态为“已取消”3会议完成后系统或用户确认 → 状态为“已完成”4设计状态机时最忌讳的是写完代码才发现状态之间可以随意乱跳比如“已拒绝”的预约还能被用户改成“待审批”这会导致逻辑漏洞。我的建议是在使用状态判断的地方统一做一个校验方法。比如取消预约时只允许从“待审批”和“已通过”这两个状态流转到“已取消”。如果需要更严谨还可以加“待签到”“已签到”等中间状态用于判断是否迟到或爽约。这套扩展万金油论文里还能多写一节。4.2 时间冲突检测的SQL原理会议室预约最核心的“为什么”是怎么判断两个时间段是否重叠这里有一个小技巧也是很多新手容易踩的坑。先给出一段错误示范判断新预约时间段[newStart, newEnd]与已存在预约[existStart, existEnd]是否冲突你可能会写成WHERE start_time #{newStart} AND end_time #{newEnd}这样只能查出“已存在的时间段完全包含在新时间段内”的情况漏掉了大量其他重叠场景。正确思路是逆否命题判断两个时间段不重叠的条件是“新结束时间 已存在开始时间 或者 新开始时间 已存在结束时间”。只要不满足“不重叠”就说明两者有交集。所以冲突检测SQL应该写成SELECT COUNT(*) FROM booking_record WHERE room_id #{roomId} AND book_date #{bookDate} AND status IN (0, 1) AND start_time #{newEnd} AND end_time #{newStart}如果查出COUNT(*) 0说明时间段重叠预约失败。这里把状态限制为“待审批”和“已通过”已拒绝、已取消、已完成的记录不参与冲突。可能你会问为什么是start_time #{newEnd} AND end_time #{newStart}而不是和那是因为如果会议结束时间和下一场开始时间相同比如第一场11:00结束第二场11:00开始从业务角度应该是允许的。所以使用严格小于、严格大于才能支持“边界连续预约”。这个问题我被问过好几次答辩时主动说出来是个加分点。4.3 预约接口的实现流程预约接口的完整流程可以归纳为六步前端提交预约表单参数包括会议室ID、日期、开始时间、结束时间、会议主题、参会人数。后端做基础参数校验比如结束时间是否晚于开始时间、是否选择了未来的日期。查询会议室是否存在且状态为启用。执行冲突检测SQL判断该会议室在目标时间段是否已被占用。若空闲插入预约记录状态为“待审批”。返回成功结果并触发消息通知如果做了通知模块。代码风格上我会把这六步逻辑全部封装在BookingService.createBooking()方法里并且保证“校验失败就立即返回不执行后续操作”。关于参数校验我再多说一句。很多初学者习惯在controller里写一堆if (xxx null)代码很冗长。更优雅的方式是直接在实体类上使用JSR 303校验注解比如NotNull、Future在controller参数上加Valid就能自动校验。这样controller层会清爽很多也显得你规范。如果对校验逻辑不熟用最原始的if判断单独写出来至少不会错。4.4 跨天和边界情况的处理数据库设计时我推荐“日期 时间字符串”的方式是因为它在处理时间段冲突时非常直观。但它有一个潜在问题如果用户输入晚间时段跨越午夜就必须单独处理。我在这版源码里直接做了限制不允许预约日期与开始时间/结束时间跨天。前端在提交时会拦截bookDate与start_time的组合后端也会二次校验比如判断起始时间是否大于等于当前系统时间针对当天以及end_time是否比start_time晚。如果想支持跨天SQL就不能简单用book_date ?来过滤而要改成判断新预约的绝对时间范围是否与已有预约的绝对时间范围重叠。这通常需要把“日期时间”拼接成一个datetime字段过程比较繁琐。建议非必要不加你的毕设已经够完整了。5. 管理端与会议室资源管理5.1 后台管理的核心功能拆解管理端是这套系统里区分“普通项目”和“完整系统”的关键。一般来说管理员需要具备以下能力第一会议室管理。管理员可以新增会议室、编辑地址和容量、配置设备清单、停用或者删除会议室。新增时需要注意停用不等于删除删除的会议室如果已有历史预约记录会导致统计信息异常所以更安全的做法是加一个status字段做逻辑删除。第二预约审批。普通用户提交预约后管理员能看到所有待审批的记录选择通过或拒绝。拒绝时必须填写原因这样用户端能清楚知道为什么被拒绝。我见过不少项目没有“拒绝原因”这个字段用户体验会差很多。第三预约记录管理。管理员可以按日期、会议室、预约人、状态筛选所有预约记录也可以手动取消某条异常预约。第四基础数据统计。如果论文需要图表这里可以加一个简单的统计模块查询一周或一个月内的会议室使用率、各会议室的预约次数排行、预约高峰时段分布。这些数据可以从一张预约记录表里Group By出来不需要额外表但写进论文里会显得系统“有分析价值”。5.2 权限设计与登录拦截权限是答辩时大概率被问到的点。这套系统的权限模型可以设计成简单的双角色模型普通用户和管理员。后端实现权限建议用一个拦截器。前端请求携带token登录时生成拦截器校验token有效性并取出当前用户角色再判断请求路径是否属于管理端接口。如果角色不是管理员直接返回403。整个过程不需要引入Spring Security或Shiro这种重型框架毕设场景下自己写个拦截器完全够用还能展示你对底层原理的理解。不过要注意一个问题前端路由守卫只能防“不懂技术的普通用户”真正防止非法访问必须靠后端拦截层。千万不要只在前端隐藏按钮就算“权限控制”我见过不少这样的项目被答辩老师一眼识破。5.3 管理端页面设计与交互管理端前端建议采用左右布局左侧菜单右侧内容区。菜单项包括“仪表盘”“会议室管理”“预约审批”“预约记录”“用户管理”等。“预约审批”页面是最能体现交互细节的地方。每行数据展示会议主题、预约人、预约时间、会议室名称后面带“通过”和“拒绝”按钮。点击“拒绝”后弹出对话框填写拒绝原因。这里有一个经验审批操作完成后不要刷新整个页面而是直接调用接口更新那一行的状态并重新拉取当前页数据这样操作反馈更顺滑用户不会觉得“卡了一下”。如果你用的前端框架是Vue 3 Element Plus表格可以用el-table日期筛选用el-date-picker分页用el-pagination组合起来半小时就能搭好一个管理页。这部分工作量不大但视觉上做好了非常加分。6. 消息通知与提醒机制6.1 站内信通知模块的实现思路会议室预约系统即使不做短信和邮件也应该有一个“站内消息”模块。预约提交成功后给用户发“预约提交成功等待审批”审批通过后发“审批已通过请按时参会”审批被拒后发“审批被拒原因XXXX”。这类消息存入数据库的消息表用户登录后在右上角小铃铛里查看未读数量。我建议消息表单独建一张字段可以包含id、user_id、title、content、type通知类型、read_status是否已读、create_time。生成消息的动作可以放在service层预约更新的代码里比如审批通过时在同一个事务里插入一条消息记录保证数据一致性。6.2 定时任务释放超时未办结的预约想做加分项的话可以引入一个定时任务对于状态为“已通过”的会议如果会议开始时间超过当前时间并且管理员没有标记完成系统可以自动判断为“已完成”或“爽约”。实现手法很简单。如果后端是Spring Boot在启动类上添加EnableScheduling在需要执行的方法上加Scheduled(cron 0 0 * * * ?)每小时执行一次批量更新UPDATE booking_record SET status 4 WHERE status 1 AND CONCAT(book_date, , end_time) NOW()这段SQL的意思是对于已经通过且结束时间早于当前时间的预约自动改为已完成。这样既能让数据保持“最新状态”又可以在答辩时展示你对定时任务的理解。7. 常见问题与部署时的排查技巧7.1 启动阶段最容易踩的5个坑我在做项目启动支持时发现下面这几个问题出现的频率特别高基本每一个都能让新手卡半小时以上。端口被占用。Spring Boot默认端口是8080如果你本地有别的服务占用了8080启动会直接报“Port already in use”。解决办法很简单在application.yml里改server.port比如改成8088。前端接接口的时候记得保持端口一致。数据库时区报错。MySQL连接串里如果缺少serverTimezoneAsia/Shanghai启动时大概率报“The server time zone value ... is unrecognized”。在JDBC连接串末尾加上参数即可解决。数据库名字大小写问题。MySQL在Linux下区分大小写Windows下默认不区分。如果你的SQL脚本里库名是meeting_room_db而配置里写成了MeetingRoomDB在Windows上可能碰巧能跑通到了Linux就出问题。建议统一用小写省心。前端跨域问题。前端地址是http://localhost:5173后端是http://localhost:8088不同端口就一定存在跨域。如果后端没有配置跨域过滤器浏览器会拦截请求。解决方式是在后端写一个实现WebMvcConfigurer的配置类或者在接口的Controller上加CrossOrigin。源码里一般已经写好但如果你自己改造接口时新增了路径要确认跨域配置依然生效。依赖下载太慢。Maven下载依赖默认从中央仓库拉取国内网络会非常慢。如果卡住建议在IDEA的Maven配置文件里设置阿里云镜像。这是性价比最高的提速方法。7.2 预约功能跑不通时的排查思路如果发现预约功能异常先别急着改代码按照下面这个顺序排查第一步看后端接口返回什么。用浏览器开发者工具打开F12切到Network面板提交预约请求后看响应状态码和返回内容。如果返回的是500后端控制台一般会有异常堆栈直接照着堆栈找原因。第二步确认数据库连接是否正常。如果执行插入或查询时报表不存在要么是表名写错要么是数据库环境选错检查application.yml里的url、username、password。第三步把冲突检测SQL单独拉出来在Navicat或命令行里手动执行一遍看看查询结果是否符合预期。很多时候代码看着没问题但SQL执行结果永远是0那就说明条件有问题。第四步查看修改后的代码是否重新编译生效了。如果你在IDEA里改了Java代码但没有重新构建运行的还是旧的class文件。养成热部署的习惯可以让这件事自动完成。我自己的排查习惯是先在浏览器里跑通一条完整链路再逐层缩小范围。从前端入参开始到后端接口再到SQL执行逐层定位基本没有搞不定的Bug。7.3 导出与部署的注意事项论文写完后很多学校要求把系统部署到服务器演示。我这里给几个部署建议能避免你在演示现场翻车。打包后端。使用Maven的package命令生成jar包然后在服务器上执行java -jar xxx.jar启动。注意正式环境不要用spring-boot-devtools热部署依赖它会在打包时引入一些奇怪的问题而且生产环境也没必要实时热部署。前端构建。Vue项目要先修改接口请求的baseURL从开发环境的http://localhost:8088改成生产环境真实域名或服务器IP然后执行npm run build生成dist目录。把dist里的静态文件放到Nginx或Apache的网站根目录。数据库初始化。服务器上的MySQL执行一遍源码自带的SQL脚本并确认字符集是utf8mb4否则存入中文会乱码。防火墙和端口。云服务器需要在安全组里开放后端端口如8088和Nginx的80端口否则外部访问不了。很多同学以为“项目起不来”实际是忘了开端口。8. 源码改造建议与论文写作衔接8.1 如果不想千人一面可以从这些方向改造直接拿源码交作业的风险在于同校或同班同学可能也用了同一份源码。为了避免答辩撞车我建议在保留核心结构的前提下做几个低成本但识别度很高的改造。第一增加“周期预约”功能。允许用户选择“每周一9点到11点连续预约一个月”系统自动生成多条预约记录。这个功能在业务上很有卖点实现时只需要在提交时根据日期循环插入即可代码量不大。第二增加“冲突推荐”。当用户选择的时间段冲突时系统自动推荐当天该会议室相邻的空闲时段或者推荐同时间段其他空闲会议室。前端展示“推荐替代方案”后端用一个简单的查询即可完成。第三增加“数据看板”。在管理端首页用ECharts做一个会议室使用率环形图、一周预约量折线图、热门会议室排行柱状图。这些数据全部来自预约记录表不涉及新增表但视觉效果和论文截图都会好很多。第四个方向是“多租户支持”也就是区分不同部门的数据。给会议室表增加一个owner_dept字段普通用户只能看到本部门的会议室。这个改动会让系统逻辑复杂一个级别但对论文的“创新点”帮助极大适合想拿优秀毕设的同学。8.2 论文结构如何与系统对应论文一般可以按这个结构组织第一章绪论写研究背景、国内外现状、研究内容和意义。背景可以写企业信息化和资源管理效率提升不要写得太宏大落到“会议室使用冲突”这个具体痛点上就好。第二章相关技术介绍介绍Spring Boot、Vue、MySQL、MyBatis Plus等。挑重点写篇幅不用太长但要让老师看出你确实会用这些技术。第三章系统分析包括可行性分析、需求分析、功能模块划分、用例图。把自己的用例图画好这是答辩时老师一眼就能看到的成果。第四章系统设计包括总体架构设计、数据库设计、接口设计。数据库设计部分把ER图和表结构贴出来不要只贴建表语句还要说明字段为什么这么设计。第五章系统实现按照功能模块逐一展示页面截图和关键代码片段。这里注意截图一定要清晰代码不要贴大段平淡无奇的挑有逻辑深度的贴比如冲突检测那段配一个时序图会非常有说服力。第六章系统测试写测试用例表和测试结果。把登录、预约、审批、冲突检测、权限拦截这些核心功能都覆盖到测试结论写“系统功能满足需求运行稳定”即可。最后一章总结与展望写你在开发过程中遇到的问题和收获以及未来可改进的方向比如增加人脸签到、与企业微信打通等。这一段我个人体会是别写“我学会了XXXX”这种空话具体到“通过解决会议室预约冲突检测问题我深入理解了数据库查询中区间重叠判断的方法”比什么都有说服力。9. 问答速查答辩高频问题与应对口径最后整理几个答辩时老师最爱问的问题提前准备好答案现场就不会慌。“你这个冲突检测是怎么实现的”把第4.2节那套SQL逻辑讲清楚即可重点强调“区间重叠的逆否条件”和“边界时间可连续预约的设计取舍”。“密码存的是明文吗”如果源码存的是明文建议改为MD5加盐或BCrypt加密并回答“考虑到安全需求对密码进行了加密存储”。即便你只改一行PasswordEncoder配置也比空着手强。“如果两个人同时提交同一个会议室的预约会不会产生冲突”这是个并发问题。方案是在冲突检测SQL基础上对room_id book_date start_time end_time加一个唯一约束或数据库锁。更讲得通的方案是使用乐观锁或悲观锁再往深一点可以提“在插入前用SELECT ... FOR UPDATE锁住该会议室当天记录”。即使你没做讲出思路也能得分。“系统能支撑多少并发”可以坦诚回答毕设场景下没有做大规模压测但系统基于Spring Boot的线程池和MySQL的InnoDB行级锁设计正常情况下一个中小型企业的会议室预约需求完全够用。如果老师追问可以提一下可以加Redis缓存或消息队列做削峰体现你有扩展意识。“前端权限控制单靠隐藏按钮够吗”这是一个陷阱题。正确的回答是“前端控制主要用于提升用户体验真正的安全性由后端拦截器保证前端按钮隐藏只是在前端做了菜单级限制后端接口均有权限校验”。准备好这些问题答辩基本稳了。根据我个人的经验会议室预约系统这类题目最怕的不是做不出来而是做完之后讲不清楚“为什么这么设计”。只要你把本文里的表结构、冲突检测、状态机、权限校验这几块的逻辑吃透无论老师在哪个角度问你都能接得住。
