本文详解 laravel 中判断预约时间区间是否重叠的正确逻辑与实现，纠正常见边界条件误判问题，提供简洁可靠的数据库查询方案及完整代码示例。
本文详解 laravel 中判断预约时间区间是否重叠的正确逻辑与实现，纠正常见边界条件误判问题，提供简洁可靠的数据库查询方案及完整代码示例。
在构建智能储物柜预约系统时，精确检测时间范围重叠是防止重复预订的核心逻辑。你当前的查询仅分别比对起止日期和起止时间，未将「日期+时间」作为统一时间点处理，导致跨时段重叠（如 19:00–21:00 与 19:30–21:30）被错误判定为无冲突——这正是典型的时间区间重叠判断逻辑缺陷。
✅ 正确的重叠判断数学原理
两个时间区间 [A, B]（用户请求）与 [Y, Z]（已有预约）存在重叠，当且仅当：
A < Z AND Y < B
即：用户开始时间早于已有结束时间 且 已有开始时间早于用户结束时间。
该条件覆盖全部四类重叠场景（包含完全包含、部分交叉、首尾相接等），且简洁高效，无需 OR 多层嵌套。
?️ 推荐实现：统一使用 datetime 字段 + 单条 WHERE 查询
首先，强烈建议将数据库字段从分离的 beginning_date/beginning_time 改为合并的 beginning_datetime 和 end_datetime（类型为 DATETIME）。这不仅简化逻辑、提升性能，更避免时区与格式解析风险。
// 在控制器中（优化后）
public function create(Request $request)
{
$locationId = $request->input('location_id');
$duration = (int) $request->input('duration');
// ✅ 统一解析为 Carbon 实例（推荐使用 ISO 格式避免解析歧义）
$beginningDatetime = Carbon::createFromFormat('Y-m-d H:i',
$request->input('beginning_date') . ' ' . $request->input('beginning_time')
);
$endDatetime = $beginningDatetime->copy()->addHours($duration);
// ✅ 核心重叠检测：一行逻辑，高可读、高可靠
$reservedCount = Reservation::where('end_datetime', '>=', $beginningDatetime)
->where('beginning_datetime', '<=', $endDatetime)
->count();
$totalBoxes = Box::where('location_id', $locationId)->count();
$available = $totalBoxes > $reservedCount;
return view('checkout', compact(
'locationId', 'beginningDatetime', 'endDatetime', 'duration', 'available'
));
}⚠️ 注意事项：
- 字段类型必须为 DATETIME 或 TIMESTAMP，确保数据库能正确比较时间点；
- 使用 Carbon::createFromFormat() 显式指定输入格式，避免 Carbon::parse() 因模糊格式（如 06/04/2022）引发地区差异；
- addHours($duration) 前务必 copy() 原实例，防止意外修改 $beginningDatetime；
- 若暂无法修改表结构，需在查询中手动拼接日期时间字符串（不推荐，性能差且易出错）：
->whereRaw("CONCAT(beginning_date, ' ', beginning_time) <= ?", [$endDatetime->format('Y-m-d H:i:s')]) ->whereRaw("CONCAT(end_date, ' ', end_time) >= ?", [$beginningDatetime->format('Y-m-d H:i:s')])
? 为什么你的原查询会失效？
你原逻辑：
->where('beginning_date', '<=', $endDate)
->where('end_date', '>=', $beginningDate)
->where('beginning_time', '<=', $endTime)
->where('end_time', '>=', $beginningTime)本质是分别校验日期和时间的独立区间，等价于 (date_overlap) AND (time_overlap)，但真实重叠需同时满足「时间轴上存在交集」，即 (datetime_overlap)。例如：
- 预约1：2022-04-06 19:00 → 2022-04-06 21:00
- 预约2：2022-04-06 19:30 → 2022-04-06 21:30
→ 日期完全相同（2022-04-06 <= 2022-04-06 AND 2022-04-06 >= 2022-04-06 ✅），
→ 时间也重叠（19:30 <= 21:30 AND 21:00 >= 19:30 ✅），
但你的查询却因 beginning_time <= endTime（19:30 <= 21:30）和 end_time >= beginningTime（21:00 >= 19:30）恒成立而漏判——根本原因在于未将二者绑定为原子时间点。
✅ 总结
- 核心公式：WHERE end_datetime >= ? AND beginning_datetime <= ? 是检测任意两区间重叠的黄金标准；
- 数据建模优先：用 DATETIME 字段替代分离的日期/时间字段，一劳永逸；
- 避免 OR 逻辑：多 orWhere 易引入 SQL 注入风险与性能开销，单 AND 条件更安全高效；
- 测试边界场景：务必验证「首尾相接」（A == Z 或 Y == B）、「完全包含」、「部分交叉」等用例。
遵循此方案，你的储物柜预约系统将具备工业级的时间冲突防护能力。
