订单快照必须固化商品字段，即下单时将商品名称、单价、SKU、图片URL、规格参数等完整拷贝进订单文档，而非仅存product_id引用实时商品数据，以避免后续商品改名、调价、下架导致历史订单显示错误。
订单快照必须固化商品字段，不能只存 product_id
直接引用商品集合（products）的实时数据，下单后商品改名、调价、下架，订单页就显示错。快照不是“关联”，是“刻录”——下单那一刻的商品名称、单价、SKU、图片 URL、规格参数，全得拷贝进订单文档。哪怕冗余，也得存。
常见错误：只存 product_id，前端查订单时再 $lookup 商品表；一旦商品被删或字段更新，历史订单就丢信息或显示异常。
- 关键字段建议固化：
name、price、original_price、sku、image_url、specifications（JSON 对象）、stock_status - 不要固化
_id以外的 ObjectId 类型字段（如category_id），避免关联失效；若需分类信息，也应拷贝category_name和category_path字符串 - 注意字段长度：商品名可能超 100 字符，MongoDB 文档单字段无硬限制，但索引字段有 1024 字节上限，
name若建索引需截断或用text索引
order_items 数组里每个条目都要独立快照
一个订单多个商品，每个 order_items 元素必须包含完整商品快照，而不是共享一份商品快照引用。否则同一商品在不同订单中价格不一致时（比如促销分时段），或某次修改影响了所有历史订单快照，就出问题。
示例结构：
{
"order_no": "ORD20240520001",
"items": [
{
"product_id": "prod_abc123",
"name": "iPhone 15 Pro 256GB",
"price": 7999.00,
"quantity": 1,
"specifications": { "color": "Titanium Black", "network": "5G" }
},
{
"product_id": "prod_def456",
"name": "USB-C 快充线（2m）",
"price": 89.00,
"quantity": 2,
"specifications": { "material": "braided nylon" }
}
]
}
- 禁止把快照提到订单顶层（如
snapshot: { products: [...] }），再让items通过索引引用——这增加读取复杂度，且易因数组顺序变更导致错位 - 如果商品支持多语言，快照应存下单时用户看到的语言版本（如
name_zh、name_en），而非依赖 locale 动态渲染
快照生成时机必须在创建订单事务内完成
不能先写订单，再异步补快照。网络超时、服务重启、并发下单都可能导致快照缺失或不一致。MongoDB 的 multi-document transaction（4.0+ 副本集 / 4.2+ 分片）能保证原子性：查商品 → 计算价格 → 写订单 + 快照，全成功或全失败。
- 事务中务必使用
session.startTransaction()，并显式commitTransaction()或abortTransaction() - 注意事务超时默认 60 秒，商品查询若带复杂聚合或未命中索引，可能触发超时，需确保
_id查询走索引，且避免在事务中做 HTTP 调用 - 如果用旧版 MongoDB 或无法启用事务，至少用
findAndModify+ 重试机制保障最终一致性，但不如事务可靠
快照字段更新不等于商品变更，别误触发库存/通知逻辑
快照是静态副本，后续对 products 集合的修改（如改价、编辑描述）不应自动同步到已有订单。但开发中常误把“更新商品”接口也去遍历更新所有关联订单的快照字段，这既慢又危险——可能覆盖用户实际支付的价格。
- 任何业务逻辑（如库存扣减、发货通知、售后凭证生成）都应基于订单文档自身字段，而非反查商品集合
- 监控告警可加一条规则：当发现订单中
items.*.price与当前products中对应product_id的price不一致时，仅记录日志，不自动修正 - 如果要做“历史价格对比展示”（如“比上次购买降了 ¥200”），需额外存
snapshot_created_at时间戳，并查该时间点的商品快照归档（而非当前商品）
真正麻烦的是规格组合爆炸——比如颜色+内存+网络制式有 12 种 SKU，快照要精确到 SKU 级别，不能只记“iPhone 15 Pro”，否则退货时无法校验实物。这个细节，上线前很容易漏测。
