一、座位状态机：用数字流转约束业务规则#

自习室座位的核心是一个状态机。reservation 表的 status 字段定义了完整流转：

这个设计的价值在于：所有业务操作最终都收敛为状态变更。

• 用户签到 → 0 → 1
• 用户暂离 → 1 → 3
• 用户回来 → 3 → 1
• 暂离超时 → 3 → 4
• 使用结束 → 1 → -1

每个状态变更都绑定一个副作用（释放座位 / 扣信用分 / 记违规），代码路径非常清晰。

二、TimerTask：异常场景的自动兜底#

系统最复杂的地方不是正常流程，而是异常场景。预约了不来怎么办？暂离了一直不回来怎么办？

项目的答案是 TimerTask 定时任务：

1
// 伪代码示意：预约超时未签到自动判违规
2
TimerTask checkSignTimeout = new TimerTask() {
3
    @Override
4
    public void run() {
5
        // 找到所有 status=0 且超过签到时间的预约
6
        List<Reservation> timeoutList = reservationMapper
7
            .findTimeoutReservations(now());
8

9
        for (Reservation r : timeoutList) {
10
            r.setStatus(2); // 未及时签到
11
            seatService.release(r.getSeatId());
12
            creditService.deduct(r.getUserId(), 10); // 扣信用分
13
            violationService.record(r.getId(), "超时未签到");
14
        }
15
    }
16
};

定时任务每 N 分钟扫一次，把「应该发生但用户没做」的事情自动补掉。这是典型的最终一致性思路——不依赖用户操作，系统自己兜底。

三、信用分：约束行为的奖惩机制#

信用分是这个系统里很巧妙的约束设计：

• 初始 100 分
• 超时未签到 → 扣分
• 暂离超时 → 扣分
• 教师可手动加/扣分
• 信用分过低 → 限制预约权限

它不是简单的惩罚，而是用分数门槛间接控制资源分配。分数低的人自动失去预约资格，不需要管理员手动拉黑。

前端：双 UI 库的组合#

这个项目的前端架构也值得注意：

• PC 端管理界面 → Element UI 2.15（给管理员/教师用）
• 移动端 H5 → Vant 2.12（给学生用）

同一套后端 API，根据设备类型加载不同的 UI 库。Axios 统一封装，通过 devServer.proxy 把 /api 代理到后端 9003 端口。

总结#

这个项目的复杂度不高，但异常处理的设计意识很到位。定时任务兜底、状态机约束流转、信用分约束行为，这三板斧在很多业务系统里都适用。

项目地址：github.com/Melusine-ichnose/Seat-Reservation-System