开学那阵子，图书馆和自习室一座难求的场面，相信大家都不陌生。我做过一次小调研，发现很多高校和共享自习室的管理还停留在"人工点名+纸质登记"的阶段，管理员要对着Excel核对座位，学生得提前一小时去排队占座。这套 SpringBoot + Vue3 + MyBatis 的 MVC 自习室管理和预约系统，就是奔着这个问题去的——用一套前后端分离的完整源码，把"预约-签到-管理-统计"这条链路彻底线上化。本文不聊浮夸的架构，直接拆解这套系统怎么设计、表怎么建、并发预约怎么防超卖、前端权限怎么控，以及部署上线时最容易踩的坑，适合正在做毕设、想上手全栈项目，或者自习室运营方想找一套现成方案的读者参考。
1. 自习室预约系统的两类核心用户与需求拆解
在动笔写代码之前，我习惯先列清楚"谁在用这个系统，他们分别要解决什么痛苦"。这套系统表面看是"自习室+预约"两个词的组合，实际上需求方分成两个完全不同的角色，功能设计必须分开对待。
1.1 学生端：我要的不是花哨，是"能约上"
学生（或者说普通用户）的核心诉求非常朴素：打开页面能看到哪些自习室有空位，选一个时间段提交预约，到点了扫码或点击签到，离开时释放座位。但"能约上"三个字背后有几个容易被忽略的细节：
- 自习室和座位是两个概念。一间自习室里有几十个座位，用户预约的粒度必须是"座位级"，不然会出现预约了自习室但进去没位置的尴尬。
- 时间段不能拍脑袋定。现实中自习室会划分时段，比如"上午 08:00-12:00""下午 14:00-18:00"，系统要能配置时段，预约时判断该座位的目标时段是否已被占用。
- 签到要有容错。路上堵了、临时有事晚来十分钟，不能直接算违约，通常给一个签到宽限期（比如预约开始后 30 分钟内可签到），超时才释放座位并记录违约。
- 个人中心必须能看到"我的预约记录"和"违约记录"，否则用户不知道自己的信用状态，后续限制预约也没法解释。
1.2 管理员端：我要的不是功能多，是"管得住"
管理员的痛点比学生更具体。首先，管理员需要维护基础数据——自习室信息（名称、位置、座位数、开放时段）、座位信息（编号、是否启用）、时段规则。其次，管理员要能查看所有预约记录，手动处理异常情况（比如用户爽约后的座位释放、纠纷申诉）。最后，统计报表是硬需求——哪个自习室使用率最高、哪个时段最拥挤、违约率有多高，这些数据直接关系到自习室的运营策略。
我做的版本里，在管理员端额外加了一个"座位状态总览"页面，用表格展示所有座位的当前状态（空闲/已预约/使用中/已禁用）。这个页面看起来不起眼，但实际运营时非常好用，管理员扫一眼就知道全场情况，不用点进每个自习室去查。
1.3 两类用户需求如何映射到功能模块
需求梳理完，功能模块基本就定了：用户认证模块（登录注册 + JWT）、自习室管理模块、座位管理模块、预约模块（核心）、签到/释放模块、违约记录模块、统计报表模块。注意预约模块一定要独立出来设计，因为它既要读写座位状态，又要生成预约记录，还要和时间段校验逻辑打交道，属于整个系统里最容易出并发问题的部分。
到这里，需求清单已经清楚，接下来就是技术选型的问题——为什么这套源码用的是 SpringBoot + Vue3 + MyBatis + MySQL，而不是其他组合。
2. 技术栈选型逻辑：为什么这套组合适合此类项目
很多初学者选技术栈是"哪个火选哪个"，但做过几个完整项目后会明白，选型看的不是流行度，而是"团队熟悉度 + 生态成熟度 + 部署成本"三者的平衡。这套系统的组合，恰好在这三点上都站得住。
2.1 SpringBoot 3.x：快速起服务，生态不用愁
后端选了 SpringBoot，核心原因是它把"能跑起来的 Web 服务"这件事的成本降到了最低。内嵌 Tomcat、自动配置、起步依赖，意味着我从零搭一个 REST API 服务只需要一个@SpringBootApplication注解和几行配置。对于自习室这种业务逻辑不算极复杂的系统，SpringBoot 的 MVC 分层（Controller -> Service -> Mapper）正好把代码组织得明明白白，后期维护不用在一堆 Servlet 和配置文件里翻找。
这里特别说下版本选择。SpringBoot 3.x 要求 JDK 17+，如果你的服务器或者本机环境还是 JDK 8，建议老老实实选 SpringBoot 2.7.x 分支，否则编译都过不了。我在这套源码里用的是 SpringBoot 3.x + JDK 17 的组合，后续部署章节会专门讲这个坑。
2.2 Vue3 + Vite：前端工程化体验更好
前端用 Vue3 是顺理成章的选择。相比 Vue2，Vue3 的组合式 API 让逻辑复用变得简单，比如预约表单的校验逻辑、token 的存取逻辑，都可以写成独立的组合函数到处复用。搭配 Vite 做构建工具，开发环境的冷启动速度快得感人，HMR（热更新）几乎是秒级响应，调试体验比 Webpack 时代舒服太多。
后台管理界面我用了 Element Plus 组件库，表格、表单、日期选择器、弹窗确认这些后台系统的高频组件开箱即用，不需要自己手写样式。如果你只需要极度轻量的前台展示页，也可以只用原生 Vue3 + 少量 CSS，但涉及管理后台这种大量表格交互的场景，组件库能省下至少一周的开发量。
2.3 MyBatis 与 MySQL：轻量且可控的数据访问层
选 MyBatis 而不是 JPA/Hibernate，是我一贯的偏好——SQL 需要手动控制。自习室预约系统里最关键的"查座位在某时段是否被占"这个操作，SQL 的写法直接关系到性能，用 MyBatis 的注解或 XML 可以清晰地看到每一条 SQL，出了问题也好排查。JPA 虽然开发快，但遇到复杂查询要么套方法名，要么写 JPQL，反而绕圈子。
MySQL 则是这类业务系统的标准答案：关系型数据模型天然匹配"用户-座位-预约"这种实体关系，事务支持成熟（InnoDB），而且部署维护的资料一搜一大把，遇到问题不容易卡住。
整个技术栈组合下来，这套系统的运行时链路是：Vue3 前端通过 Axios 调用 SpringBoot 的 REST 接口，SpringBoot 通过 MyBatis 访问 MySQL，鉴权走 JWT + 拦截器。链路简单清晰，出现问题能快速定位是前端、后端还是数据库的问题。
3. 数据库与表结构设计：预约核心是"座位+时段"的唯一性
数据库设计是我做这类系统耗时最多的部分。表建得不好，后面写代码会处处别扭。我强烈建议，任何系统先花一天时间把 ER 图和表结构定下来，再开始写代码。自习室系统的核心表，大致是下面这 6 张。
3.1 核心表清单与字段说明
- 用户表（sys_user）：id、username、password（BCrypt 加密存储）、real_name、phone、role（0 学生/1 管理员）、status、create_time。注意密码千万不要明文存，这个没得商量。
- 自习室表（study_room）：id、room_name、location、total_seats、open_time、close_time、status、description。open_time 和 close_time 用 time 类型或字符串（"08:00:00"）都行，记住在代码里统一格式。
- 座位表（seat）：id、room_id、seat_number、status（0 可用/1 禁用）。seat_number 在同一个自习室内唯一，用复合唯一索引
(room_id, seat_number)约束。 - 预约记录表（reservation）：id、user_id、seat_id、room_id、reserve_date、time_slot_id、status（0 已预约/1 已签到/2 已释放/3 已爽约/4 已取消）、create_time、signin_time。这张表是系统的核心，字段看起来简单，但查询频率最高。
- 时段表（time_slot）：id、slot_name、start_time、end_time。比如"上午 08:00-12:00""晚间 18:00-22:00"。
- 违约记录表（violation）：id、user_id、reservation_id、reason、create_time。用户爽约或者超时未签到，这里就多一条记录。
3.2 预约唯一性如何保障：表设计的关键所在
"同一个座位在同一个日期 + 同一个时段只能被预约一次"，这个约束是整个系统的命根子。它不能只靠代码判断，必须在数据库层面做到：
- 在预约记录表建立唯一索引：
UNIQUE KEY uk_seat_slot (seat_id, reserve_date, time_slot_id)。 - 插入预约记录前，先执行查询确认该组合不存在"已预约/已签到"状态的记录。
- 唯一索引 + 代码双重校验。数据库的唯一索引是最后一道防线，即使代码逻辑出现并发漏洞，数据库也会拒绝重复插入，避免数据脏掉。
3.3 为什么需要单独设计时段表
有人问，时段不就"上午下午晚上"三个吗，写死在代码里不就行了？这属于典型的"开发一时爽，运营火葬场"。自习室的开放时段会随着季节、节假日调整，如果写死在代码里，改一次时段就要重新发一次版。单独建一张时段表，管理员在后台界面上就能增删改时段，预约表单的时段选项动态从接口读取，这才是可维护的设计。
3.4 关于软删除与状态字段
我在所有业务表里都保留了 status 字段做逻辑删除/禁用，而不是直接物理 DELETE。比如座位被禁用，不是删除记录，而是把 status 置为 1。这样历史预约记录里的座位信息仍然是完整的，统计报表也不会因为物理删除而数据断层。这个习惯在真实项目里非常重要——凡是涉及历史业务数据的表，尽量别物理删。
4. 后端核心实现：预约防并发与状态流转是硬骨头
后端你看代码的话，会发现 Controller 层都很薄，真正的工作量都在 Service 层，尤其是预约相关的那几个方法。这里挑三个最容易出问题的点展开讲，都是实战中踩过的坑。
4.1 JWT 鉴权与拦截器：前后端分离的登录态方案
前后端分离的项目，Session 方案天然不合适（跨域、集群共享都是问题），JWT 是事实标准。我在项目里的做法是：
- 用户登录成功后，后端生成 JWT 字符串返回给前端，
expiration设置为 2 小时。 - 前端把 JWT 存到 localStorage，每次 Axios 请求在请求拦截器里带上
Authorization: Bearer <token>。 - 后端写一个
JwtInterceptor，实现HandlerInterceptor接口，在preHandle里校验 token 是否有效、是否过期。校验通过就把用户 id 和角色塞进ThreadLocal或 request attribute，后续 Controller 方法直接取。
这里有个容易踩的坑：拦截器拦截了/api/**的所有请求，但登录接口/api/auth/login和注册接口/api/auth/register必须放行，否则用户根本登不进去。我在代码里用excludePathPatterns配置了一个白名单数组，凡是新增的公开接口（比如获取自习室列表的预览接口），都要记得加进去。
4.2 预约座位与防超卖：事务 + 锁怎么配合
预约的核心流程是：校验用户未违约超限 -> 校验座位存在且启用 -> 校验时段未占用 -> 创建预约记录 -> 更新座位状态。这个流程存在并发风险——两个用户同时预约同一个座位，如果都通过了第 3 步校验，就会产生两条预约记录。
数据库唯一索引兜底，但用户体验上会出现"请求成功但实际插入失败"的问题。所以我在 Service 层做了两层防护：
第一层，悲观锁。查询"座位是否被占用"时，使用SELECT ... FOR UPDATE锁住座位行记录，事务提交后锁释放。这个方案实现简单，正确性有保障，缺点是并发量高时锁等待会影响吞吐。对于自习室这种 TPS 几十的规模，悲观锁完全够用。
第二层，事务控制。整个"校验 + 插入预约 + 更新座位"放在一个@Transactional方法里，任何一个环节异常，全部回滚，避免出现"预约记录建立但座位状态没更新"的中间态。
我实际验证过，即使用 JMeter 模拟 50 个并发同时抢同一个座位，最终能成功入库的也只有一条预约记录，其他请求要么被唯一索引拒绝，要么被行锁挡住。这就是事务和锁配合的效果。
4.3 预约状态机：每个状态怎么流转
预约记录的状态字段有 0~4，很多人写代码时直接在业务逻辑里if status == 1 then status = 2，这样写一时爽，后期加需求时状态判断越叠越乱。我用一个简单的状态机来规范流转：
- 预约（0）
- 签到（1）：用户到馆，点击签到或扫描二维码。前置状态必须是 0，且当前时间在预约时段内（或宽限期内）。
- 释放（2）：用户主动离开，或已签到用户的时段结束。前置状态是 1。
- 爽约（3）：预约时段开始后 30 分钟未签到，由定时任务自动置为 3，并生成违约记录。
- 取消（4）：用户在预约时段开始前主动取消。前置状态是 0，超过段起时间不允许取消。
我把状态流转校验独立封装成一个ReservationStateMachine工具类，每个状态转移方法里先校验前置状态，再返回新的状态。这样做的好处是，任何入口要改变预约状态，都得走状态机，不会出现某个"野路子"逻辑直接把状态改飞。
4.4 定时任务处理爽约
爽约的自动标记需要定时任务。我在项目里用的 Spring 自带@Scheduled注解，启动类加@EnableScheduling，然后写一个任务方法，每 5 分钟扫描一次"预约日期等于今天、时段已开始超过 30 分钟、状态仍为 0"的记录，批量更新为 3 并插入违约记录。
这里有个性能细节：扫描条件和更新条件要用索引字段（reserve_date、time_slot_id），否则表数据量大了以后定时任务会拖慢数据库。我实际观察过，几千条预约记录的体量下，这个任务每次执行都在 10 毫秒以内，完全不是瓶颈。
5. 前端 Vue3 落地要点：路由守卫、状态管理与接口封装
前端代码的结构我按 Vite + Vue3 + Pinia + Element Plus 组织。表面上这就是标准后台前端模板，但有几个细节值得单独说，因为这些细节直接决定了开发效率和后期维护的舒适度。
5.1 前端路由权限控制：动态路由还是简单守卫？
自习室系统的角色只有两种（学生/管理员），没必要用动态路由那种重方案。我采用的是"路由守卫 + 菜单控制"的轻量做法：
- 路由表里给管理端页面添加
meta: { roles: ['admin'] }标记。 router.beforeEach守卫里，先判 vue-router 的全局守卫中用户是否已登录（localStorage 有无 token），没有就去登录页；有 token 再判断目标路由的 roles 是否包含当前用户的角色，不匹配就重定向到 403 页面。
这么做的原因是，对于角色固定、权限粒度粗的系统，动态路由（后端根据角色返回路由表，前端动态 addRoute）带来的复杂度大于收益。写起来还容易出"刷新页面后路由丢失"的问题，排查成本很高。
5.2 Pinia 管理用户信息与座位状态
Vue3 官方推荐 Pinia 做状态管理，这次我确实没再用 Vuex。用 Pinia 存两个关键东西：
userStore：存用户 id、昵称、角色、token。登录成功后调用userStore.setUserInfo()，前端所有组件共享，不用每个页面都从 localStorage 读。roomStore：存自习室列表和选了自习室之后的座位列表，避免在多个页面间反复请求相同数据。
有一个经验值得分享：Pinia 的 store 里只存"需要跨组件共享的数据"，不要什么都往里面放。比如某个页面独有的表单草稿，放在组件自己的ref里就行，放进 store 反而会产生"这个数据为什么被改了"的调试难题。
5.3 Axios 拦截器：统一错误处理与 token 刷新问题
我在src/utils/request.js里封装了 Axios 实例，三个拦截器逻辑：
- 请求拦截器：自动加 token。
- 响应拦截器：统一解包
res.data；如果 code 为 401，说明 token 失效，清空本地用户信息并跳转登录页；如果 code 为其他业务错误码，统一通过 Element Plus 的ElMessage弹出错误提示。 - 错误处理：网络错误、超时等统一提示。
这里对"401 后跳登录页"有个坑——如果多个接口同时失败，会触发多次跳转。我习惯加一个isRedirecting标志位，跳转前判断是否已经在跳转过程中，避免重复跳转导致路由栈混乱。
5.4 预约流程的前端交互设计
预约操作不是简单的"点击提交按钮"。为了减少无效提交，前端交互上我做了三个细节：
预约前先选日期，再选时段，然后加载座位列表。座位的颜色标记状态——绿色空闲、灰色已占用、红色已禁用。选中灰色座位时直接禁用提交按钮，同时给出提示。这一步能挡掉大量无意义的接口请求。
提交预约前弹确认框，显示"座位号 + 日期 + 时段"的摘要信息，让用户二次确认。这个设计对减少错误预约有奇效，我实测下来误触率降了一大截。
预约成功后，前端不急着跳转，而是展示预约详情和"签到提醒"（比如提示可以提前 30 分钟到馆签到）。把后续动作直接摆到用户面前，能显著降低爽约率。
6. 联调与部署：从本地跑通到上线，我踩过的实物坑
这部分是"眼睛看到"和"血泪教训"的分水岭。代码在本地跑通只算完成了 60%，联调和部署阶段才是真正磨人的地方。挑四个最常见的坑，给正准备把这套系统部署上线的朋友提个醒。
6.1 跨域配置：前端端口 5173 访问后端 8080 怎么放行
Vite 默认端口 5173，后端 8080，前端直接fetch必然跨域。我提供两套方案，二选一即可：
- 方案 A（开发环境）：Vite 配置
server.proxy，把/api前缀的请求代理到http://localhost:8080，前端代码里统一走相对路径/api/xxx。这个方案的好处是浏览器请求的是同源地址，不存在跨域问题，也不需要后端开 CORS。 - 方案 B（生产环境）：Nginx 统一入口，
location /api代理到后端服务。
在我这套源码里，采用的是方案 A 的配置（Vite proxy），后端同时加了WebMvcConfigurer的跨域配置，方便直接部署到测试环境的人。注意跨域配置要写在 Spring 的addCorsMappings里，允许来源*，允许方法GET, POST, PUT, DELETE, OPTIONS。
6.2 JWT 密钥与时长配置
JWT 密钥是写在application.yml里的，比如studyroom.jwt.secret。这个值在生产环境一定要改成复杂的随机字符串，且通过环境变量注入，不能提交到代码仓库。JWT 过期时间我默认 7200 秒（2 小时），但真实场景下用户可能坐在自习室里一待就是一下午，2 小时过期后请求全部 401，体验很糟糕。建议改成 7200 秒的 2 倍（4 小时），或者实现"刷新 token"的机制。
前端收到 401 后直接踢出登录页，这个逻辑对长时间停留的用户不太友好。我后来加了一个简单的"无感刷新"：响应拦截器发现 401 时，先尝试调用/api/auth/refresh接口刷新 token，成功了就自动重发原请求。不过这个功能依赖后端提供一个 refresh 接口，属于增强项，基础版本里没包含。
6.3 SpringBoot 3.x + JDK 17 的部署注意事项
很多人的生产服务器还是 CentOS 7 + JDK 8，直接把 SpringBoot 3.x 的 jar 丢上去，会直接报UnsupportedClassVersionError。这一点在选型时必须提前确认。我在源码 README 里明确写了环境要求：JDK 17+、MySQL 5.7+（或 8.0+）、Node.js 16+（构建前端用）。
部署时如果服务器上没有 JDK 17，两个思路：装一个 Oracle JDK 17，或者用 docker 镜像打包。我个人的建议是，如果条件允许，直接用 Docker 编排后端服务 + MySQL 是最省心的方式，避免环境差异带来的各种诡异问题。
6.4 Nginx 部署前端并解决 Vue Router 刷新 404
前端npm run build之后生成 dist 目录，放到 Nginx 的html目录，访问首页没有问理。但如果有人直接访问/seats这种深层路由，刷新页面就会出现 404，因为 Nginx 找不到对应的静态文件。
标准解法是在 Nginx 配置里加一个try_files：
location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }try_files的作用是：如果请求的不是真实文件，就统一返回index.html，由 Vue 的路由接管页面渲染。这个配置不加上，部署完测试时一定会遇到——所以我先写在这里，免得你查到半夜。
6.5 MySQL 时区导致的时间错乱
最后一个高频坑：MySQL 的时区设置和 Java 的时区不一致，导致存入数据库的时间比实际时间差了 8 小时或 13 小时。我在连接串里显式指定了serverTimezone=Asia/Shanghai，在 Spring 配置里设置了spring.jackson.time-zone=GMT+8，数据库连接 URL 保持统一。
如果你发现预约记录的 create_time 和实际时间对不上，优先检查这三处是否完全一致。这是最容易忽略、又最影响体验的问题。
7. 系统管理与统计报表：看似简单实则提升运营效率的功能
预约把用户端搞定后，管理者看着后台一堆数据，最想的其实是"到底哪个自习室热门、哪个时段闲置"。所以统计报表不是可有可无，是这套系统价值感的直接体现。
7.1 使用率统计的 SQL 思路
我实现了一个报表接口，返回每个自习室在某个日期范围内的预约使用率。核心 SQL 思路是：先查出该自习室的座位总数，再统计某天有预约记录（状态为已签到/已预约）的座位时段数，两者相除得到使用率。这类统计天然适合用 MyBatis 写原生 SQL，用 JPA 反而绕。
在性能上，统计接口可能会被频繁刷新，我做了一层简单的缓存——Redis 或者 Caffeine 都行。我基础版本里用的 Caffeine，5 分钟过期，报表数据本身就不要求绝对实时，缓存 5 分钟完全能接受。
7.2 违约机制如何影响预约权限
学生的违约次数累计到一定值（比如 3 次），系统应该限制其下月不能再预约。这个逻辑放在用户登录和预约两个入口同时校验：登录时查出违约次数，超过阈值就在前端顶部展示警告；预约时后端直接拒绝，返回"违约次数超限，请联系管理员"。
这套机制能让使用者对规则产生敬畏感。如果没有这个约束，座位预约服务的公信力很快就会崩掉——毕竟谁也不想约了位置被一堆人放鸽子。
8. 扩展思路：从"自习室"到"通用资源预约"
最后说一下这个项目后续还能怎么演。这套系统的表结构和预约流程，本质上是"资源 + 时段 + 用户 + 状态机"的通用模型。把自习室表换成会议室、把座位表换成设备、把时段表换成可配置规则，就是一套会议室预约系统；加上付款字段，就能扩展成付费的共享工位租赁系统。
我在源码里刻意没有把业务写死，比如座位表和自习室表中间留了足够的扩展字段（description、remark），预约记录表也带了 room_id，方便后期做跨房间查询。如果你打算在这个项目基础上做二次开发，我的建议是：
- 不要轻易改动预约状态机那部分代码，那是整个系统的核心骨架。
- 数据库结构如果没想清楚，宁可不加字段，也不要乱加无索引的字段。
- 前端组件如果要做功能扩充，优先复用 Element Plus 提供的现成组件，自己封装高级组件要慎重。
自习室预约这个选题，技术难度不高，但麻雀虽小五脏俱全——认证、权限、事务、并发、定时任务、统计报表，全栈开发的核心知识点都覆盖到了。我把这套系统源码的架构和实现思路拆到这里，希望能给正在做类似项目的人一些参考。如果你动手实现过程中遇到并发预约或者 Nginx 部署上的问题，按上面说的思路排查，基本都能落地解决。
