订单状态变更应弃用status字段，改用order_events集合记录不可变事件，含复合时间戳和全局单调seq；所有相关集合须统一shard key（如user_id）；快照数据需分离存储并避免冗余嵌套。
订单主表必须用不可变流水替代状态字段更新
直接在 orders 文档里用 updateOne({ _id }, { $set: { status: "shipped" } }) 改状态，等于主动放弃历史可追溯性。一旦出问题，你连“谁在什么时候把订单从 paid 改成 shipped”都查不到。
正确做法是彻底弃用 status 字段，改为只存基础元数据（order_id、user_id、total、create_time），所有状态变更都写入独立的 order_events 集合：
- 每条事件文档含
order_id、event_type（枚举值如"created"、"paid"、"shipped"）、timestamp、by_user_id、metadata（轻量上下文，比如支付渠道、物流单号） -
timestamp必须用{ timestamp: Date, seq: Number }复合结构，避免毫秒级时钟漂移导致sort({ timestamp: 1 })乱序 - 给
{ order_id: 1, timestamp: -1, seq: -1 }建复合索引，查最新状态不走内存排序
快照不能靠 readConcern: "snapshot" 在事务里硬读
很多人在事务中写“先查当前状态再决定是否发货”，顺手加 readConcern: { level: "snapshot" }，结果遇到 SnapshotTooOld 错误或逻辑错乱——因为 snapshot 时间戳无法早于事务 startTimestamp，且它不包含本事务已做的修改。
真正可控的快照语义是：用带条件的原子更新代替读-改-写。
- 发货动作应写为：
order_events.insertOne({ order_id, event_type: "shipped", timestamp: new Date(), seq: nextSeq() }, { session }) - 同时用
orders.updateOne({ _id: orderId, latest_event_id: { $ne: insertedId } }, { $set: { latest_event_id: insertedId } }, { session })更新主表指针，确保 latest_event_id 与事件强一致 - 不要依赖
find({ order_id }).sort({ timestamp: -1 }).limit(1)查最新——没索引就是全表扫，有索引也扛不住分布式时钟误差
分片集群下所有相关数据必须路由到同一 shard
如果你的 orders 按 order_id 分片，order_events 却按 user_id 分片，一次“创建订单 + 写创建事件 + 写支付事件”的事务会跨多个 shard，触发两阶段提交（2PC），prepare 阶段锁粒度扩大、延迟飙升、超时风险陡增。
- 强制所有订单相关集合（
orders、order_events、inventory_snapshots）使用相同shard key，推荐统一用user_id - 在分片集群中执行
sh.status()，确认每个 shard 的状态是HEALTHY，且mongos能连通所有 shard primary - 本地开发用单节点
mongod启动？别试事务——session.startTransaction()会静默失败或抛CommandNotFound，先跑db.runCommand({ replSetGetStatus: 1 })确认副本集就绪
快照数据必须分离存储且禁止嵌套冗余
别把完整订单快照（含 items 数组、address 对象、paymentDetails）一股脑塞进 order_events 文档。这会导致三类问题：文档体积膨胀逼近 16MB 上限、更新成本高（每次改地址都要重写整个快照）、同步延迟风险放大（一个大文档复制慢，secondary 落后多）。
- 快照只存关键字段：
amount、currency、shipping_status、payment_method，长度可控、语义稳定 - 商品明细、收货地址等长尾字段，用
item_ids: [ObjectId]或address_id: ObjectId引用方式存，查详情时再按需拉取 - 如果业务要求“下单即通知最新快照”，用 Kafka 解耦：写完
order_events后发消息，下游服务异步构建并写入order_snapshots集合，避免事务阻塞
seq 生成必须全局唯一且单调递增，shard key 选错会导致事务代价指数上升，这两处一旦上线就极难调整。 
