管理系统被说「太普通」，往往不是缺微服务，而是主流程没有一条硬规则。冲突检测就是最稳的那条：同一实验室（房间/设备）在重叠时段不能被两个「已通过」预约占住。整套预约骨架见 实验室预约落地文；本页只把冲突写死。
一句话规则：同一 resource_id，新预约时段与已占用时段相交，则拒绝。相交判定：newStart < oldEnd AND oldStart < newEnd。
一、先定「什么叫占用」
| 状态 | 默认是否占用 | 说明 |
|---|---|---|
| 待审核 | 否 | 可允许多单待审，审核时再查一次 |
| 已通过 / 进行中 | 是 | 必须参与冲突 |
| 已驳回 / 已取消 / 已完成 | 否 | 释放时段 |
规则写进开题和论文「业务约束」一节。不要答辩现场才改。
二、判定式（背下来）
半开区间 [start, end) 更不容易边界重复：
冲突 ⇔ newStart < oldEnd 且 oldStart < newEnd
不冲突 ⇔ newEnd <= oldStart 或 oldEnd <= newStart- 单位统一：全用
LocalDateTime或全用时间戳，别混字符串 end必须严格大于start- 跨天预约：要么禁止，要么按天拆段后再判
三、SQL 思路（MySQL）
SELECT id FROM booking
WHERE resource_id = ?
AND status IN ('APPROVED','ONGOING')
AND start_time < ?
AND end_time > ?
AND id <> ? -- 改约时排除自己
LIMIT 1;查到一行就返回业务错误，例如：CONFLICT: 该时段已被预约。不要只打日志还返回 200。
四、接口放哪
- 学生提交预约：insert 前查冲突
- 管理员点通过：改状态前再查一次（防待审期间被别人先通过）
- 改时段：带上
id <> self
两处都查，比「只在前端 disable 按钮」靠谱。前端灰掉只是体验，不是约束。
五、最少测例（答辩可演示）
| 已有 | 新预约 | 期望 |
|---|---|---|
| 10:00–12:00 | 12:00–13:00 | 通过（点接壤） |
| 10:00–12:00 | 11:00–11:30 | 拒绝（被包含） |
| 10:00–12:00 | 09:00–11:00 | 拒绝（左重叠） |
| 10:00–12:00 已取消 | 10:30–11:00 | 通过 |
六、答辩怎么讲 30 秒
「同一实验室同一时间只允许一个已通过预约。用时间段相交公式在提交和审核两处校验，测了包含、左重叠、点接壤和取消后重约。这是业务约束，不是调参模型。」
别说「我用了算法」。老师要的是规则清楚、测例在、代码找得到。
常见问题
时间段冲突怎么判断？
两段 [aStart,aEnd) 与 [bStart,bEnd) 相交，当且仅当 aStart < bEnd 且 bStart < aEnd。
待审核要不要互斥？
默认不互斥；通过时再查。若学院要求「提交即占坑」，开题写死并全站统一。
订房、会议室能套吗？
能。把 resource 换成房间/车位/设备即可，公式不变。