2. 技术选型与架构设计
2.1 为什么选择 Java + SpringBoot
自习室管理系统这种业务，本质上是典型的“管理信息系统”开发，核心诉求是稳定、快速交付、后续好维护。我在技术选型时几乎没有犹豫就锁定了 Java + SpringBoot 的组合，不是说其他技术栈不好，而是这个组合在高校毕设场景下的综合性价比实在太高。
Java 作为后端语言，最大的优势是生态成熟。你随便搜一下就能发现，Java 相关的开源库、文档、社区讨论量大得惊人，遇到问题基本都能搜到现成答案。SpringBoot 则把 Spring 框架中大量繁琐的 XML 配置全部干掉，通过自动配置和起步依赖，让我能用一个 main 方法就把整个 Web 服务跑起来。对于自习室预约这种 CRUD 为主的业务系统，SpringBoot 的开发效率比传统 SSM 架构高出一大截。
从运行环境角度说，Java 是跨平台的，不管是部署在实验室的 Windows 服务器，还是云上的 Linux 主机，一套 JDK 就能搞定。而且 Java 的稳定性是经过十几年大规模企业应用验证的，自习室系统的核心诉求是“别出幺蛾子”，这种保守但可靠的选择恰好符合业务定位。
2.2 整体架构：前后端分离还是传统 MVC
这里要解释一个关键决策：我最终采用的是基于 Thymeleaf 模板引擎的传统服务端渲染 MVC 架构，而不是时下流行的前后端分离方案。原因有两点。
第一，毕设项目的重点在于业务逻辑的完整性和系统功能的覆盖面，前后端分离意味着要同时维护 Vue 前端工程和 SpringBoot 后端工程，工作量直接翻倍，还要处理跨域、Token 认证、接口文档维护等一系列额外问题。第二，自习室管理系统本身的页面交互并不复杂，核心就是预约、计时、管理这三个场景，服务端渲染完全够用，而且整站只有一个打包产物，部署时丢进 Tomcat 或直接用 java -jar 启动就行，省心。
架构分层上，我按照经典的三层架构来组织：
- Controller 层：负责接收 HTTP 请求、参数校验、调用 Service 服务
- Service 层：承载核心业务逻辑，比如预约冲突检测、计时状态流转
- Mapper 层：基于 MyBatis-Plus 操作数据库，DAO 级别的数据访问
实体类上，我设计了 User（用户）、Seat（座位）、Reservation（预约记录）、UsageRecord（使用记录）、Announcement（公告）这几个核心表。表结构设计时我特别在意时间字段的处理，因为预约计时是整个系统最核心的功能，时间精度直接决定计费逻辑的对错。
2.3 数据库设计：自习室业务的核心是状态管理
自习室预约系统本质上是在管理两种资源的状态：座位的状态和预约记录的状态。我花了很多时间在状态机的设计上，这里展开说说。
座位表 seat 设计如下：
- id：主键
- seat_number：座位编号，如 A-01
- area：区域（A区、B区等）
- status：0空闲 1已预约 2使用中 3维护中
- is_valid：逻辑删除标记
预约记录表 reservation 的字段：
- id：主键
- user_id：预约用户
- seat_id：预约座位
- start_time：预约开始时间
- end_time：预约结束时间
- status：0待使用 1已签到 2已取消 3已完成 4违约
这里要重点解释 status 字段的设计。一开始很多同学会把预约状态设计成单一字段，但实际业务中一个预约从创建到结束会经历多种状态转换：用户提交预约 → 待使用 → 到馆签到 → 使用中 → 手动结束或超时结束。如果不把状态机梳理清楚，后面写业务逻辑时会出现大量 if-else 分支，而且很容易漏掉某个状态的边界情况。
我推荐的方案是预约记录和实际使用记录分开两张表。预约表管“用户和座位的预约关系”，使用记录表管“用户实际在座位上的起止时间”，这样即使预约取消了，也不影响已经产生的使用记录统计。很多网上公开的毕设项目喜欢把这两者混在一起，结果导致统计报表时数据一团糟。
2.4 核心功能拆解：预约、签到、计时、管理
整个系统的功能可以分成两条线：学生端和管理员端。
学生端的核心流程是：注册登录 → 查看自习室座位图 → 选择空闲座位预约 → 到馆签到 → 使用座位 → 结束使用。这里有个容易被忽略的点：预约和签到之间的时间窗口。我设置了预约后 15 分钟内必须签到，否则视为违约并释放座位，这个规则既保证了座位利用率，又不会给学生造成太大压力。
管理员端的核心功能是：座位管理、预约记录查询、用户管理、违约记录管理、公告发布、数据统计。数据统计这部分我做了按日预约量、座位使用率、高峰时段三个维度的报表，用 ECharts 在前端展示柱状图和折线图，这个功能在项目答辩时非常加分，因为它体现了系统不只是 CRUD，还有数据驱动的管理价值。
计时功能是系统的技术难点。我采用了“数据库记录 + Redis 缓存”的双层方案：Redis 缓存当前进行中的预约会话，保证查询状态时速度快；数据库负责持久化最终的使用记录，确保数据不丢失。每次客户端发起签到或结束请求时，服务端统一以服务器时间为准计算时长，避免客户端本地时间被篡改的问题。
3. 核心细节解析与实操要点
3.1 SpringBoot 版本选择：别盲目追新
写这篇博客的时候，SpringBoot 已经迭代到了 3.x 版本，很多初学者一上来就创建最新的 SpringBoot 3.x 项目，然后在配置 MyBatis-Plus、连接数据库时遇到一堆兼容性问题，卡了好几天没进展。
我个人的建议是：毕设项目用 SpringBoot 2.7.x 版本就够了。一个关键原因是 SpringBoot 3.x 基于 Jakarta EE，很多老旧教程中的 javax.* 包名已经改成了 jakarta.*，如果你跟着网上的教程敲代码，会发现 import 语句全都报错。另外一个问题是 SpringBoot 3.x 要求 JDK 17 以上，而很多学校实验室的机器还停留在 JDK 8，环境就过不去。
SpringBoot 2.7.x 是最后支持 javax 包名的版本，也是兼容 JDK 8 的版本，网上能找到的海量教程、踩坑文章绝大多数围绕这个版本段展开。用 2.7.x 等于站在了巨人的肩膀上，遇到问题基本都能搜到解决方案。学习项目时选稳定版本，工作中再按需升级，这个思路在软件工程里叫“保守依赖原则”。
3.2 MyBatis-Plus 的妙用：从实体类直接生成建表 SQL
说到 MyBatis-Plus，这是我觉得比 MyBatis 原生更适合毕设项目的 ORM 框架。它最大的优点是内置了通用 Mapper 和通用 Service，意味着基础的单表 CRUD 你几乎不用写 SQL，只写一个继承 BaseMapper 的接口就能获得 insert、delete、update、select 的全部能力。
更赞的是，MyBatis-Plus 配合 SpringBoot 的自动配置，可以直接根据实体类生成建表 SQL。我用的具体方式是：在实体类上写好 @TableName、@TableId、@TableField 注解，然后在测试类里调用 MyBatis-Plus 的 TableInfoHelper 来获取建表语句。
@Test public void generateCreateTableSql() { TableInfo tableInfo = TableInfoHelper.initTableInfo( new MapperBuilderAssistant(new MybatisConfiguration(), ""), User.class); System.out.println(tableInfo.getCreateSql()); }这段代码会把 User 实体对应的建表 SQL 打印出来，你复制到数据库管理工具里执行就行。这个功能的实际意义在于：实体类是你写业务代码时维护的“单一事实来源”，数据库表结构随着实体类走，改实体类后重新生成 SQL 就能对得上，避免了手写 SQL 和实体类字段不一致的经典问题。
3.3 座位预约的并发冲突处理：悲观锁还是乐观锁
座位预约系统有个典型的高并发场景：多个学生同时抢同一个座位。如果只是简单地在 Service 层做查询再插入，大概率会出现同一个座位被多人同时预约成功的情况。这个问题在答辩时会被老师专门问到，所以必须处理好。
我的实现方案是：在座位表上增加一个 version 字段，每次预约操作时先查询当前版本号，更新座位状态时带上 version = #{version} 的条件，如果更新影响行数为 0，说明版本已被其他请求修改，就返回“座位已被预约”的提示。
@Update("UPDATE seat SET status = 1, version = version + 1 WHERE id = #{seatId} AND status = 0 AND version = #{version}") int occupySeat(@Param("seatId") Long seatId, @Param("version") Integer version);这种乐观锁方案比直接给整张表加悲观锁更轻量，在学生用户量不大的大学校园场景下完全够用。说实话，自习室系统的并发压力远没有电商秒杀那么大，但能在方案层面体现出你考虑过并发问题，这就是一个亮点。
另外一个容易忽略的点是预约的唯一性约束：同一时间段内同一用户只能有一个有效的预约记录。这个我在数据库层面加了联合唯一索引，同时在 Service 层也做了前置校验，双保险。数据库约束是最后一道防线，不能只依赖代码逻辑。
3.4 计时精度与超时任务：定时器方案选型
自习室计时系统里有一个“定时任务”需求：预约超时未签到要自动取消，使用中超时未结束要自动结算。实现定时任务有三种常见方案，我对比一下。
第一种是 Spring 自带的 @Scheduled 注解，实现简单，但默认是单线程串行执行，如果你的任务逻辑里涉及网络请求或者复杂计算，会阻塞后续任务。第二种是 Quartz 框架，功能强大，支持集群分布式部署，但对于一个小型毕设项目来说有点杀鸡焉用牛刀。第三种是基于 Redis 过期事件或者延迟队列来实现，更进阶但复杂度也更高。
我最终选的是 @Scheduled + 自定义线程池的折中方案。每 30 秒执行一次扫描任务，把超过 15 分钟未签到的预约批量更新为已取消状态，把使用时长超过预约时长的记录做特殊标记。实际线上跑下来，扫描单表几万条数据的时间在几十毫秒量级，完全能满足业务需求。
这里要特别提醒一个经验：定时任务的执行频率不要设置太频繁，否则数据库压力会很大。我在开发时一度把扫描间隔设成了每 5 秒一次，结果数据库 CPU 直接飙高，后来改成 30 秒才恢复平稳。做定时任务时要问自己一个问题：业务上能容忍的最大延迟是多少？对于签到超时取消来说，30 秒的延迟学生根本感知不到，那就没必要用 5 秒去折腾数据库。
4. 实操过程与核心环节实现
4.1 环境准备与项目初始化
工欲善其事，必先利其器。我开发的完整环境如下，你可以直接照抄：
- JDK 1.8（对应 SpringBoot 2.7.x）
- Maven 3.6+ 或更高版本
- MySQL 5.7+（建议用 8.0，字符集选 utf8mb4）
- Redis 6.x（用于缓存和会话管理）
- IDEA 2023 版本（社区版也够用）
- Navicat 或 DataGrip 作为数据库客户端
创建 SpringBoot 项目时，我推荐用 IDEA 自带的 Spring Initializr。这里有个小技巧：如果你使用 start.spring.io 在线生成，要注意选择正确的 SpringBoot 版本，默认展示的往往是 3.x 版本。我习惯在 Spring Initializr 页面先把版本切成 2.7.18，再点生成，这样不会拿到一个与自己环境不匹配的骨架。
项目的基础依赖只需要引入这几个：spring-boot-starter-web（Web 能力）、spring-boot-starter-thymeleaf（模板引擎）、mybatis-plus-boot-starter（ORM）、mysql-connector-java（数据库驱动）、spring-boot-starter-data-redis（缓存）、lombok（简化实体类代码）。其他像 spring-boot-starter-security 我一开始就没引入，因为自习室系统的登录认证自己写拦截器就够了，引入安全框架反而增加了配置复杂度。
4.2 登录认证模块：拦截器 + JWT
关于登录认证，我对比过 Session 和 JWT 两种方案。传统的 Session 方案简单可靠，服务端存储用户的登录状态，但缺点是在前后端分离或集群部署时会遇到共享问题。因为是单体应用，我最终采用了 Session + 拦截器的组合，这也是最稳妥的方案，毕竟自习室系统的用户数撑死几千人，Session 完全没压力。
拦截器实现的关键代码如下：
public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }然后在 WebMvcConfigurer 中注册拦截器，并配置排除路径（登录页、注册接口、静态资源）。
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/css/**", "/js/**", "/images/**"); } }这段配置的价值在于：任何人访问除登录注册之外的任意页面，都会被强制跳转到登录页。如果你对权限粒度有更细的要求（比如区分学生和管理员），可以在 Session 中存储用户角色，然后在拦截器中增加角色判断。
4.3 预约核心流程的完整实现
预约流程是整个系统最复杂的部分，我把它拆成五个步骤实现：
第一步，前端页面加载座位图。座位图我用 HTML + CSS 绘制，每个座位是一个 div，点击后触发预约弹窗。这一步的关键是前端要能区分座位的四种状态，我通过后端接口返回的 seat.status 字段控制 CSS 类名，分别渲染为绿色（空闲）、黄色（已预约）、红色（使用中）、灰色（维护中）。
第二步，前端发起预约请求，携带 seatId 和 userId。后端 Service 接收请求后，先检查当前用户是否有未结束的有效预约，防止重复预约。这个检查的逻辑是：
long count = reservationMapper.selectCount(new LambdaQueryWrapper<Reservation>() .eq(Reservation::getUserId, userId) .in(Reservation::getStatus, 0, 1)); if (count > 0) { throw new BusinessException("您已有未完成的预约，请先结束当前预约"); }第三步，执行乐观锁更新座位状态。这一步代码前面已经展示过，核心是 status 和 version 的双条件更新。
第四步，插入预约记录，初始状态设为 0（待使用），预约开始时间默认是当前时间 + 15 分钟（允许学生在预约后 15 分钟内到馆签到）。这里有一个设计细节：预约的“预计开始时间”不影响用户实际开始使用的记录，用户如果提前到了，可以马上签到，系统以签到时间作为计时的起点。
第五步，预约成功后跳转到“我的预约”页面。页面上提供签到按钮和取消按钮，如果用户在预约后 15 分钟内点击签到，预约状态变为 1（已签到），同时生成一条使用记录，座位状态变为 2（使用中）。如果用户主动取消，预约状态变为 2（已取消），座位释放回 0（空闲）。
整个流程的关键逻辑我都写了单元测试验证，特别是乐观锁的并发场景，用两个线程同时预约同一个座位，断言只有一个能成功。这一步对避免答辩翻车很重要，建议你也花时间写。
4.4 座位计时与自动结算模块
计时模块的存储设计是：使用记录表 usage_record 中有一个 begin_time 和 end_time 字段。用户签到时写入 begin_time，用户点击“结束使用”时写入 end_time，时长通过 end_time - begin_time 计算。
但这里有个坑：如果用户忘记点结束使用就离开，座位会一直处于使用中状态，后面想预约这个座位的学生就会看到它被占用。所以我的系统里设置了一个自动任务：每 30 秒扫描一次使用中状态的座位，如果一个使用记录的 begin_time 距离当前时间超过 4 小时（即预约的最大时段），系统会自动结束这个使用记录，并把座位释放为空闲。
@Component public class SeatTimeoutTask { @Scheduled(fixedDelay = 30000) public void autoReleaseSeat() { LocalDateTime threshold = LocalDateTime.now().minusHours(4); List<UsageRecord> overdueRecords = usageRecordMapper.selectList( new LambdaQueryWrapper<UsageRecord>() .eq(UsageRecord::getStatus, 1) .lt(UsageRecord::getBeginTime, threshold)); for (UsageRecord record : overdueRecords) { record.setEndTime(LocalDateTime.now()); record.setStatus(2); // 已结束 usageRecordMapper.updateById(record); // 释放对应座位 seatMapper.updateStatus(record.getSeatId(), 0); } } }这段逻辑很直接，但有个细节必须注意：循环里更新座位状态时，不能使用乐观锁的 status = 0 条件，因为座位当前状态是被占用，应该使用 status = 2 来释放。统一用 0 条件会导致 SQL 更新失败，我当时在这上面调了好一阵，属于典型的“看似简单实则容易错”的场景。
4.5 数据可视化页面实现
管理端首页展示三个核心指标：今日预约量、当前使用人数、累计使用时长。下面用 ECharts 画两个图表：近 7 日预约量趋势折线图，以及不同区域座位使用率柱状图。
前端引入 ECharts 的方式很简单，在 HTML 中通过 CDN 引入：
<script src="https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js"></script>然后后端提供一个查询统计数据的接口：
@GetMapping("/admin/stats/trend") public Result<List<DailyStatVO>> trend() { List<DailyStatVO> list = reservationMapper.selectDailyTrend(7); return Result.success(list); }前端拿到数据后初始化图表：
var chart = echarts.init(document.getElementById('trendChart')); var xData = data.map(d => d.date); var yData = data.map(d => d.count); chart.setOption({ xAxis: { type: 'category', data: xData }, yAxis: { type: 'value' }, series: [{ type: 'line', data: yData, smooth: true }] });这个可视化功能本身不复杂，但答辩时老师看到管理端有图表，第一印象就是“这个系统有数据分析意识”，比纯表格展示高一个档次。
5. 常见问题与实战避坑
5.1 SpringBoot 项目启动失败的 5 个常见原因
开发过程中我遇到最多的坑就是项目启动失败，归纳起来主要有五类：
第一，端口被占用。SpringBoot 默认端口是 8080，如果你本地同时跑着其他 Web 服务，就会报“Port 8080 was already in use”。解决方法是修改 application.yml 中的端口配置，或者直接用命令行参数启动：java -jar app.jar --server.port=8081。
第二，数据库连接失败。错误信息通常是 “Access denied for user” 或者 “Communications link failure”。前者是账号密码或权限问题，后者多半是 MySQL 服务没启动，或者连接串中的地址端口写错。检查顺序是：先确认 MySQL 服务启动（Windows 下查看服务列表，Linux 下 systemctl status mysqld），再确认 application.yml 中的 url、username、password 和实际环境一致。
第三，Redis 连接失败。因为我在系统中使用了 Redis 做计时缓存，如果 Redis 服务没启动，SpringBoot 启动时就会报 “Unable to connect to Redis”。解决方法是本机先启动 redis-server，或者临时注释掉 Redis 相关依赖和配置，让项目先跑起来。
第四，依赖冲突。Maven 项目有时会报 “Invalid content was found in Spring Configuration” 或者类找不到异常，多半是 jar 包版本冲突。用 mvn dependency:tree 查看依赖树，找出冲突版本，用 Maven 的 exclusion 排除掉多余依赖。
第五，SpringBoot 版本过高导致 javax 包名问题。如果你建的是 SpringBoot 3.x 项目，代码里 import javax.servlet.* 会直接报错，因为已经被替换为 jakarta.servlet.*。这类问题最隐蔽，新手可能查半天也不知道原因。
5.2 MyBatis-Plus 字段映射遗漏的问题
MyBatis-Plus 默认将实体类的驼峰属性名映射为数据库的下划线字段，比如实体类的 beginTime 自动映射到数据库的 begin_time。这个默认行为需要满足一个前提：spring.jackson 和 MyBatis-Plus 的驼峰映射开关要打开。
如果数据库字段名和实体类属性名规则不一致，可以用 @TableField 注解显式指定：
@TableField("begin_time") private LocalDateTime beginTime;还有一种常见问题是：查询结果中某个字段一直为 null，但数据库里明明有值。很多时候是实体类字段上一不小心加了 @TableField(exist = false) 注解，或者字段名拼写错误。用 MyBatis-Plus 时如果遇到某个字段查不出来，优先检查注解和字段名的对应关系。
5.3 前端页面刷新后 Session 丢失
我在开发时遇到一个很困惑的问题：登录后跳转到首页正常操作，但是按 F5 刷新页面就跳回了登录页。排查下来发现原因是 Session 的存储问题。SpringBoot 默认 Session 存储在内存中，如果项目设置了 context-path（比如 server.servlet.context-path=/study），那么 Session 的 Cookie 路径也要对应调整。
解决方案是在配置文件中设置：
server: servlet: context-path: /study session: cookie: path: /study如果设置不正确，浏览器拿到 Cookie 后发现当前请求路径不在 Cookie 的 path 范围内，就不会携带 Cookie，服务端自然取不到 Session。
还有一个更隐蔽的问题：前后端分离时跨域请求默认不带 Cookie。如果你使用 fetch 或 axios 调用后端接口，需要在请求中开启 credentials: 'include'，后端也要配置允许跨域并允许携带凭证。因为我的系统是服务端渲染的，没有这个问题，但如果你改造为前后端分离，这个坑大概率会遇到。
5.4 时间类字段的序列化问题
Java 8 的 LocalDateTime 在和前端进行 JSON 交互时，默认会被序列化成数组格式，比如 "beginTime": [2024, 5, 20, 10, 30, 0]，前端根本没法直接用。这个问题有两个解决思路。
方案一：在 application.yml 中配置全局 JSON 格式化：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8方案二：在实体类字段上加注解：
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private LocalDateTime beginTime;第一个方案适合大多数场景，但如果个别接口需要不同格式的日期输出，就得用方案二单独标记。还有一个细节：数据库连接串上要加 serverTimezone=Asia/Shanghai，否则 JDBC 驱动可能按照默认时区处理时间，导致数据库里的时间和你本地时间差 8 个小时。这个时区问题我调试了整整一个晚上才搞定，现在写出来，希望你能绕开这个坑。
5.5 部署上线时路径大小写和静态资源 404 的问题
本地开发一切正常，打包部署到服务器访问时，CSS、JS 文件全部 404。这个问题的根源是 Linux 文件系统是区分大小写的，而 Windows 不区分。SpringBoot 的内嵌 Tomcat 在 Windows 上对 /Css/style.css 和 /css/style.css 一视同仁，但到了 Linux 上就严格区分了。
排查方法很简单：打开浏览器 F12 开发者工具，看 Network 面板中 404 资源的完整路径，和实际文件路径做对比。我踩过一次坑后养成了一个习惯：发布前全局搜索项目中的静态资源引用路径，统一改为全小写，避免大小写不一致的问题。
另外，如果你使用了 Thymeleaf 模板，页面中引用资源时最好使用 Thymeleaf 的语法：
<link th:href="@{/css/style.css}" rel="stylesheet" />这样 SpringBoot 会自动加上 context-path 前缀，避免部署时资源路径出错。
6. 项目扩展与升级方向
自习室管理系统做完后，如果你想让项目更有亮点，可以从几个方向做扩展。
第一个方向是引入 Redis 缓存预约状态和座位列表。我在核心功能中已经做了一部分 Redis 应用，但如果想深度展示，可以把座位状态直接缓存到 Redis 中，用 Redis 的 hash 结构存储每个座位的最新状态，前端查询时直接走缓存，数据库只负责持久化。这个方案可以让你在答辩时聊聊缓存一致性和性能优化的话题。
第二个方向是把传统服务端渲染改成前后端分离，前端用 Vue 3 + Element Plus，后端只提供 RESTful API。改造后的系统在技术广度上加分明显，但工作量也不小，需要额外处理跨域配置、Token 认证、前端路由守卫等。如果时间和精力充裕，这个方向确实值得尝试。
第三个方向是加入消息通知机制。比如座位预约成功后，通过消息队列或 WebSocket 给学生端推送通知，或者实现一个简单的邮件提醒——预约时段开始前 10 分钟自动发邮件。这个功能可以展示你对 Spring Boot 整合消息中间件的能力。
第四个方向是数据统计的深化。目前我做的统计还停留在预约量和座位使用率，你还可以加入学习时长的个人统计、按学院/专业维度分析使用情况、热门时段推荐等。如果引入简单的推荐算法，还能进一步提升项目的新颖度。
这些扩展方向我建议根据自己的时间精力有选择地做，不要贪多。一个能够稳定运行、逻辑完善、文档齐全的系统，比一个功能堆砌但处处是 bug 的系统，得分要高得多。质量永远是第一位的。
7. 写在最后的一些心得体会
做自习室管理系统这个项目，前后加起来花了我三周左右的时间，其中真正写代码的时间不到一半，更多的精力花在了需求分析、表结构设计、状态流转梳理和反复的 bug 调试上。
回过头来看，最有价值的一段经历是处理预约并发冲突的问题。当时为了验证乐观锁是否真的能防止重复预约，我写了一个多线程测试，跑了十几遍，观察数据变化，最终理解了 CAS 机制在数据库层的落地方案。这种从原理到实践的完整链路，比单纯照着教程敲代码记住的东西要牢固得多。
我也踩过不少印象深刻的坑：时区问题、Session 丢失、静态资源 404、SpringBoot 版本不匹配。这些坑折磨人的时候确实很痛苦，但是解决一个就长一分经验。现在我把它们写在这篇博客里，就是希望后做的同学能少走一些弯路。
最后给你一个建议：做毕设项目时，不要急于写代码，先画清楚实体关系图、把各个功能的状态流转用文字描述一遍，这些准备工作看起来不产代码，但能帮你把后续的坑提前挖出来填平。代码写完后，一定要把部署文档和操作日志写完整，这不仅仅是为了答辩，也是将来面对工作时的一种好习惯。
自习室管理系统的本质是基于 Web 的预约资源调度，理解了它的核心逻辑，其实外卖座位、会议室预约、机房机位管理这类系统，你都能很快上手。技术栈可能会变，但业务建模的思路是不变的，这才是这个项目带给你最大的价值。
