必须将每日房态作为最小存储单元，因区间存储会导致并发冲突、查询性能差及原子性难保障；应采用房型+日期的扁平化文档结构，配唯一复合索引与条件更新实现安全锁房。
连续日期锁房为什么不能只存 start/end 时间段
直接用 start_date 和 end_date 两个字段表示锁房区间看似简洁，但会破坏房态查询的原子性和并发安全性。MongoDB 的写操作无法在不读取当前状态的前提下，安全地判断「某天是否已被锁」——比如两个请求同时想锁 2025-04-10，一个查到没锁、另一个也查到没锁，然后都写入，就产生冲突。
更实际的问题是：房态日历需要支持按「单日」高频查询（如前端点击某天看可订房型），也需支持「跨多日筛选可用房型」（如用户选 4.10–4.14）。若只存区间，每次查单日都要做日期重叠计算，索引无法高效命中；而查多日可用性时又得反向展开所有区间再做集合运算，性能随数据增长急剧下降。
- 必须把「每日房态」作为最小写入/查询单元，哪怕逻辑上是连续锁房
-
date字段必须建索引，类型为Date（不是字符串） - 不要试图用 $expr + $gte/$lte 做运行时日期重叠判断来替代每日文档
推荐结构：每个房型+每日一条文档
采用「扁平化日粒度文档」，每条记录代表「某个房型在某天的状态」，例如：
{
"room_type_id": "rt_101",
"date": ISODate("2025-04-10"),
"status": "locked",
"reason": "maintenance",
"locked_by": "admin_233",
"updated_at": ISODate("2025-04-08T14:22:01Z")
}
这种结构让以下操作变得简单可靠：
- 查某天某房型是否可订：
find({room_type_id: "rt_101", date: ISODate("2025-04-10"), status: "available"}) - 批量锁连续 5 天：
insertMany([...5 条文档...])，配合唯一复合索引{room_type_id: 1, date: 1}防止重复写入 - 查 4.10–4.14 全部可订房型：
find({room_type_id: {$in: [...]}, date: {$gte: d1, $lte: d2}, status: "available"})，再按room_type_id分组统计天数是否等于 5
如何原子性锁一段连续日期（避免部分写入失败）
MongoDB 没有跨文档事务的强一致性保障（尤其在分片集群），所以「锁 7 天」不能靠单个 updateOne 或 insertOne 完成。必须用 insertMany + 唯一索引 + 重试逻辑来模拟原子性：
- 先确保已建唯一索引：
db.room_calendar.createIndex({room_type_id: 1, date: 1}, {unique: true}) - 生成 7 天的文档数组，调用
insertMany(docs, {ordered: false})，ordered: false确保部分失败不影响其余插入 - 检查返回结果中的
writeErrors：如果某天已存在（code: 11000），说明已被锁，需业务层决定是跳过、报错或覆盖（覆盖需额外 update 操作） - 不要用 upsert 替代 insertMany —— upsert 在高并发下可能意外创建冗余文档（比如两个请求同时 upsert 同一天，都触发 insert）
锁房与房态更新的并发控制要点
真实场景中，锁房（后台操作）和用户预订（前台操作）可能同时修改同一天状态。仅靠唯一索引不够，需结合条件更新：
- 用户预订某天某房型前，必须用
findOneAndUpdate带{status: "available"}条件，避免覆盖已锁状态 - 示例：
findOneAndUpdate({room_type_id: "rt_101", date: d, status: "available"}, {$set: {status: "booked", ...}}, {returnDocument: "after"}) - 若返回 null，说明当天已被锁或已订，前端应提示「房态变化，请刷新」
- 后台锁房操作本身一般不需要条件检查（因为锁是主动管理行为），但要避免误删已有预订记录 —— 所以
status字段设计必须区分"locked"、"booked"、"available"、"cleaning"等明确语义值，不能混用布尔字段
连续锁房不是技术难点，难的是让每一天的状态变更都可追溯、可验证、可并发安全。越想省事存区间，后期越容易在查询性能、数据一致性和调试成本上付出代价。
