Node.js基于MongoDB实现含预留机制的产品日限购额度计算咨询

针对你基于MongoDB落地单日限购的场景，完全不需要设计复杂的跨集合关联逻辑，围绕两个核心业务规则（1小时预留自动失效、自然日维度额度重置、两种占用态的额度累加），存储结构可以按三层逻辑落地：

预留锁单集合（reserved_locks） #

专门存储所有用户发起的预留锁单记录，字段设计完全匹配自动释放的逻辑：

• _id: ObjectId，默认主键
• productId: String，产品不可变唯一标识（不要用会被商家修改的productName做关联键），建立单字段索引
• productName: String，冗余存储的产品名称，避免列表查询时跨表关联的性能损耗
• userId: String，发起锁单的用户唯一ID
• lockQuantity: Number，单次锁单占用的限购额度数（默认值为1，支持弹性配置多件锁单）
• lockExpireAt: Date，锁单到期时间，即锁单发起时间+1小时，是判断预留是否有效占用的核心依据
• lockStatus: String，枚举值仅保留三类：ACTIVE（有效占用额度中）、CONVERTED（已转正式付款订单，不再占用预留额度）、EXPIRED（超时未履约无额度占用）
• convertedOrderId: String，预留转正式订单时关联的采购订单ID，未转单时为空

必建复合索引：{ productId: 1, lockStatus: 1, lockExpireAt: 1 }，这个索引可以把每次计算有效预留额度的扫描范围压缩到最小，避免全表扫描。

正式采购订单集合（purchase_orders） #

存储所有用户直接下单、预留转单的正式交易记录，支撑自然日维度的额度统计：

• _id: ObjectId，默认主键
• productId: String，关联产品不可变唯一标识，建立单字段索引
• productName: String，冗余产品名称
• userId: String，下单用户唯一ID
• orderQuantity: Number，订单占用的当日限购额度数
• orderDay: Date，订单归属的自然日时间戳（取订单创建当日0点的标准化时间），是实现每日额度自动重置的核心字段
• orderStatus: String，枚举值仅保留三类：PAID（已付款，永久占用当日限购额度）、CANCELLED（取消不占额度）、REFUNDED（退款不占额度）
• sourceLockId: String，预留转单时关联的锁单ID，直接下单的记录此字段为空

必建复合索引：{ productId: 1, orderDay: 1, orderStatus: 1 }，把当日有效订单的扫描范围压到索引级。

所有限购计算逻辑不需要依赖复杂的定时任务，靠上述存储结构的字段过滤即可完全覆盖：

• 有效占用额度计算规则：某产品当日已占用总额度 = 当日归属下，purchase_orders集合中状态为PAID的订单总量 + 该产品下状态为ACTIVE、且lockExpireAt > 当前时间的预留锁单总量。计算时不需要主动把过期锁单的状态改成EXPIRED，只要加时间过滤条件，自然就排除了失效的锁单，过期记录留存作为审计日志，定期归档清理即可。
• 场景1适配（预留到期未付款）：因为计算额度时只取未过期的ACTIVE锁单，Adam的预留超时后，对应的锁单自然被排除在占用额度外，Tom的页面会自动看到额度恢复，完全不需要人工或定时任务触发额度释放。
• 场景2适配（预留有效期内付款）：用户付款时，直接把对应锁单的状态改成CONVERTED，同时在purchase_orders集合新增一条PAID状态的订单，关联对应的sourceLockId。此时计算额度时，Adam的预留锁单因为状态变化不再被计入预留占用，但其对应的已付款订单会计入当日总量，刚好实现“两个额度占满需等次日重置”的规则——因为次日计算订单占用时，会自动按orderDay字段过滤到新的自然日，旧的订单不会再被计入新一天的额度统计，不需要写单独的零点重置脚本。

如果每次加载产品列表，都实时去两个集合做聚合算额度，会带来明显的性能损耗，直接在原有产品Schema（带productName、limitPerDay的那个集合）上冗余两个计数字段即可：

• currentDayUsedQuota: Number，实时记录当前已被占用的总额度（有效预留+已付款订单的总和）
• quotaResetTime: Date，当日额度的零点重置时间戳

每次发生额度变动（发起预留、预留转付款、用户取消订单、直接下单付款）时，直接用MongoDB的原子$inc操作更新currentDayUsedQuota的值即可。

「LIMIT EXCEEDED」标签判断逻辑完全简化：只要当前用户没有在该产品的有效占用记录里（既无有效预留锁单，也无当日已付款订单），且currentDayUsedQuota >= limitPerDay，就直接展示标签，查询响应可以做到毫秒级。

避坑提醒 #

• 绝对不要用可变的productName做集合间的关联键，商家修改产品名称后会直接导致所有关联记录的逻辑断裂，必须用不可变的productId做外键
• 不要依赖定时任务批量扫描过期锁单、刷状态，一来会有状态延迟，二来批量刷库的写入压力大，靠查询时的时间过滤即可实现自动释放
• 每日额度重置不需要单独写脚本操作数据库，靠orderDay的自然日过滤逻辑，零点后会自动进入新的统计周期，不存在跨日计算的问题

内容的提问来源于stack exchange，提问作者Muhammad Siraj