电商里的「交易快照」：为什么不能只存商品 ID

电商里最常叫的是：交易快照 / 订单商品快照（Order Snapshot）。
本质不是新框架，而是一种历史事实固化的数据设计：下单瞬间把关键信息拷进订单，之后以单据为准。

1. 它叫什么

日常沟通里说「交易快照」就够了；说「快照技术」容易和虚拟机快照、存储快照搞混——电商里它是业务数据模式，不是基础设施。

2. 要解决什么问题

商品会变价、改名、换图、下架；用户账户也会换卡。

如果订单只存 product_id，展示时再 JOIN 商品表：

• 去年 99 元买的，今天显示 199
• 纠纷时对不上「当时买的到底是什么」
• 发票、售后、分佣、分账全可能算错

交易一旦发生，成交事实不应随主数据漂移。快照就是把「那一刻的约定」冻在订单上。

3. 怎么存（实现很朴素）

没有单独的 Snapshot 中间件，就是：

1. 下单时读商品/规格/佣金/备注 schema
2. 写入订单明细的普通列：product_name、unit_price、product_image…
3. 以后查订单，优先读这些列，不再用当前商品价还原成交信息

product_id 仍可保留，用于跳转、统计、运营分析；展示与结算以快照列为准。

伪代码：

4. 什么该快照，什么不该

适合快照（影响钱、履约、凭证）：

• 商品名、规格名、图片、单价、数量、优惠后金额
• 佣金比例、抽奖额度
• 下单备注字段定义（label/type）
• 提现账户信息、分账接收方与比例

通常不该快照（只要最新态）：

• 收藏夹、浏览足迹、购物车草稿
• 运营配置预览

原则：会参与对账/售后/展示历史的，就快照；只是「关注最新」的，就 JOIN。

5. 和相近概念的区别

6. 收益与代价

收益：历史稳定、纠纷可举证、查询少 JOIN、分佣/分账口径清晰。
代价：字段冗余；改商品不会回写老单（这是特性不是 bug）；要约定「以后以哪份数据为准」。

7. 一句话收束

电商「交易快照」= 在下单等关键时刻，把影响成交的信息冗余写入订单，形成不可变的历史事实；它不叫高科技组件，而是交易系统的基本功。