MongoDB订单号必须用counters集合+原子更新实现，因ObjectId不可读、不连续、难对账；counters需语义化_id如"order_id"、统一字段seq；findOneAndUpdate须设upsert:true、returnDocument:"after"、$inc:{seq:1}；拼接前缀和时间戳在应用层完成，counters集合不可分片。
MongoDB 本身不支持 SQL 风格的自增主键，但订单号这类连续、可读、需全局唯一且带业务含义的 ID，必须靠 counters 集合 + 原子更新来兜底。这不是“替代方案”，而是生产环境里最稳的路径。
为什么不能直接用 ObjectId 当订单号
订单号要满足：人类可读、按时间/顺序大致递增、便于对账和客服查询。ObjectId 是 12 字节随机散列，含时间戳但不可控、不连续、难记忆。用它当订单号，前端展示、日志排查、财务核验都会多绕三步。
- 时间戳部分只精确到秒，同一秒内多个订单会乱序
- 机器标识和进程 ID 在容器化部署下极易重复或跳变
- 无法保证
_id插入顺序 = 业务发生顺序（尤其跨分片时）
counters 集合初始化与字段命名规范
别用模糊名如 "seq" 或 "counter"，每个业务序列必须有明确语义化的 _id，比如 "order_id"、"invoice_no"。字段名也建议统一为 seq（短、通用、避免大小写歧义），而不是 sequence_value 或 next_val。
- 创建集合：
db.createCollection("counters") - 初始化计数器（仅一次）：
db.counters.insertOne({_id: "order_id", seq: 0}) - 如果怕漏初始化，
upsert: true必须开启，否则并发插入首单可能报错
findOneAndUpdate 是唯一靠谱的原子操作
findAndModify 已被弃用，MongoDB 4.2+ 必须用 findOneAndUpdate。关键参数不是可选——少一个就可能丢数据或重复。
-
returnDocument: "after"（或旧版new: true）：必须返回更新后的文档，否则拿到的是旧值 -
upsert: true：首次调用时自动建文档，避免手动判断是否存在 -
$inc: {seq: 1}：只增不查不设，杜绝竞态条件 - 示例函数（Node.js）：
async function getNextOrderId() { const result = await db.collection("counters").findOneAndUpdate( { _id: "order_id" }, { $inc: { seq: 1 } }, { returnDocument: "after", upsert: true } ); return result.value.seq; }
订单号拼接与并发安全边界
拿到纯数字 seq 后，别直接当订单号用。要加前缀、时间戳片段、校验位等，比如 ORD2026041700001。但注意：拼接动作必须在应用层做，不能塞进 MongoDB 更新语句里——否则无法原子保障。
- 前缀（如
"ORD"）和日期（如YYYYMMDD）可由应用生成，不参与计数器更新 - 纯数字部分（如
00001）必须来自counters的原子返回值 - 高并发场景下，
counters集合会成为热点，但这是可控代价；比起用count()+insert()这种非原子组合，它仍是唯一能防重的手段
真正容易被忽略的点是：计数器集合本身不能分片。哪怕你的 orders 集合已分片，counters 必须保持单节点写入，否则 findOneAndUpdate 的原子性就垮了。
