奶茶余香1. 项目背景与毕设选题价值
1.1 为什么选了自习室座位预约这个题目
每到考研季、期末周，高校图书馆和自习室里一座难求的现象几乎成了常态。我见过太多同学早上六点去排队占座，结果发现桌子上一摞书放了三天人没来；也见过有人在门口徘徊半小时找不着空位，而热门区域的座位利用率其实不到一半。自习室座位预约系统解决的正是这个真实痛点：把座位的分配从“人肉占座”变成“线上预约”，通过数据把闲置座位释放出来，让有限的资源服务更多人。
这个题目作为计算机毕业设计，性价比非常高。一方面它属于典型的信息管理系统（MIS）范畴，需求边界清晰、业务逻辑不复杂，非常适合用 Spring Boot 这种主流框架来落地；另一方面它的业务场景贴近校园生活，需求分析、原型设计、数据库建模都有大量现成素材可以参考，答辩时评委一听就懂，不会出现“你这个题目到底解决什么问题”的尴尬局面。更重要的是，系统的核心流程——用户注册登录、座位信息展示、预约创建、取消、签到、违约判定——覆盖了一个 Web 系统从数据建模到接口设计的完整链路，写进简历里也是能讲清楚的项目。
1.2 这类系统能扩展到哪些场景
座位预约只是“预约类系统”的一个缩影。同样的架构和流程，改改业务表就能延伸到很多场景：图书馆阅览室座位、高校实验室机位、驾校场地训练时段、自习室付费时段、会议室工位共享……核心都是“资源 + 时间段 + 用户 + 状态流转”这四件事。做毕设选这样一个有扩展空间的题目，后续不管是写论文还是答辩扩展提问，你都有的聊。
另外，“计算机毕业设计源码36958”这个编号说明它是一套完整交付的源码工程。对做毕设的同学来说，拿到源码不是终点，能读懂结构、能跑起来、能讲清楚每个模块为什么这么设计，才是答辩过关的关键。这篇文章我就把整套系统从技术选型到核心代码实现，按我实际做项目的思路完整拆解一遍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与整体架构拆解
2.1 为什么用 Spring Boot 而不是 SSH 或 SSM
很多学校的课程还停留在 Spring MVC + Spring + MyBatis 的 SSM 组合，但毕设这个节点，我强烈建议直接用 Spring Boot。原因很实际：SSM 里大量的 XML 配置、jar 包版本冲突、Tomcat 部署步骤，每一项都在消耗你本来该花在业务代码上的时间。Spring Boot 通过自动配置把“约定大于配置”做到了极致，一个 SpringApplication.run() 就能把 Web 容器、数据源、MyBatis、事务管理全部拉起来，这对学生党来说是降维打击。
选型时要注意版本匹配。Spring Boot 2.x 和 3.x 的差异不小，3.x 要求 JDK 17+，部分老教程里的 javax.* 包要改成 jakarta.*。如果学校机房环境还停留在 JDK 8，建议老老实实用 Spring Boot 2.7.x；如果自己的电脑是 JDK 17/21，那直接用 3.x 也没毛病。做毕设千万不要追求“最新”，稳定跑起来比什么都强。
技术栈清单大概是这样的：
| 层次 | 选型 | 说明 |
|---|---|---|
| 后端框架 | Spring Boot 2.7.x / 3.x | 提供 RESTful API，内置 Tomcat |
| 持久层 | MyBatis Plus | 比原生 MyBatis 省掉大量 SQL 编写 |
| 数据库 | MySQL 8.0 | 开源稳定，支持事务和行级锁 |
| 前端 | Vue 2/3 + Element UI | 后台管理界面开发效率高 |
| 构建工具 | Maven | 依赖管理和项目构建 |
| 鉴权 | JWT + Spring Security 或拦截器 | 简单的 Token 校验方案 |
| 缓存（可选） | Redis | 用于座位状态缓存、预约计数 |
2.2 系统功能模块怎么划分
座位预约系统的功能模块，我按用户角色拆成两端：管理员端和学生/普通用户端。这个划分方式符合绝大多数校园场景的真实权限模型。
- 用户模块：注册、登录、个人信息维护、密码修改。
- 座位管理：管理员维护自习室楼层、区域、座位编号，座位有状态（可用/占用/维护中）。
- 预约管理：用户查看座位、选定时间段、提交预约；管理员可查看全部预约记录、处理违约记录。
- 签到管理：预约生效后用户在自习室扫码或输入预约号签到，超时未签到自动释放座位并计入违约。
- 公告模块：管理员发布自习室开放时间、节假日安排、系统维护通知。
- 统计模块：座位使用率、预约频次、高峰时段分析，用柱状图或折线图展示。
数据库层面，核心表我建议至少设计这六张：user（用户表）、room（自习室表）、seat（座位表）、reservation（预约记录表）、check_in（签到记录表）、violation（违约记录表）。如果要做公告，再增加 notice 表；要做时段管理，可以加 time_slot 表。
2.3 核心流程与状态机设计
预约系统的核心不是 CRUD，而是状态流转。座位和预约都有状态，状态之间怎么跳转，决定了系统会不会出现“座位被别人约了还能约”“预约了不去也没事”这类逻辑漏洞。
预约记录的状态字段我定义为：PENDING（待签到）、CHECKED_IN（已签到）、COMPLETED（已完成）、CANCELLED（已取消）、EXPIRED（已过期/爽约）、RELEASED（超时释放）。
流程大致是这样的：
- 用户选择自习室座位和时间段，提交预约，生成预约记录（状态 PENDING）。
- 系统锁定座位在当前时间段（座位状态为 OCCUPIED）。
- 用户在预约时间段开始前后一段时间内签到，状态变 CHECKED_IN。
- 时间段结束，系统定时任务将 CHECKED_IN 转为 COMPLETED，释放座位。
- 用户主动取消，且离预约开始还有足够时间，状态变 CANCELLED，释放座位。
- 预约开始后用户未签到，超过宽限期（比如 15 分钟），状态变 EXPIRED，座位释放，违约记录 +1。
这个状态机想清楚了，后面的 service 层代码就是在“正确的时间做正确的状态迁移”。
3. 数据库设计详解与建表 SQL
3.1 表结构设计的核心思路
数据库设计是毕设答辩提问的高频区。很多同学建表就是随手一写，字段能跑就行，可一旦被问“为什么这个字段要加唯一索引”“为什么预约表要冗余座位号”，就答不上来。所以表设计必须有意识地去体现一些规范性的思考。
设计座位相关表时，核心思路是“自习室 → 区域/楼层 → 座位”这样一个层级关系。room 表和 seat 表用 room_id 关联，seat 表里存 seat_number（座位编号）、seat_type（普通座/靠窗座/静音区座）、status（0占用 1空闲 2维护）。预约表不要直接存一个 JSON 时间段字符串，而是拆成 reserve_date（预约日期）、start_time（开始时间）、end_time（结束时间）三个字段，这样做时间段冲突检测时 SQL 才能写得出来。
用户表我通常会增加 user_no（学号/工号）、role（1管理员 0普通用户）、credit_score（信用分）字段。信用分机制是预约系统的点睛之笔：每次违约扣 10 分，信用分低于 60 分限制预约，这样既惩罚了恶意占座，又不至于一棍子打死，答辩讲到这个地方评委会觉得你有思考。
3.2 核心建表 SQL 示例
下面给出一份可运行的 MySQL 建表 SQL，字段注释已经写得比较完整，拿到可以直接用。
sql复制CREATE DATABASE IF NOT EXISTS study_room DEFAULT CHARACTER SET utf8mb4;
USE study_room;
-- 用户表
CREATE TABLE `user` (
`id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID',
`user_no` VARCHAR(32) NOT NULL COMMENT '学号/工号',
`username` VARCHAR(50) NOT NULL COMMENT '用户名',
`password` VARCHAR(100) NOT NULL COMMENT '密码(MD5/BCrypt加密)',
`real_name` VARCHAR(50) DEFAULT NULL COMMENT '真实姓名',
`phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号',
`role` TINYINT NOT NULL DEFAULT 0 COMMENT '角色 0-用户 1-管理员',
`credit_score` INT NOT NULL DEFAULT 100 COMMENT '信用分',
`status` TINYINT NOT NULL DEFAULT 1 COMMENT '状态 1-正常 0-禁用',
`create_time` DATETIME DEFAULT CURRENT_T