拉卡拉开放平台

买一件商品，系统里会同时产生好几张单。它们名字相似，记录的内容却完全不同。分不清这三者，是很多电商系统后期混乱的起点。

三类单据各记什么

为什么不能合并

合并成一张表，短期看起来省事，但很快就会遇到无法表达的情形：

• 一个订单分多次支付，合并表里放不下；
• 一个订单拆成多个包裹，物流信息无处安放；
• 部分退款时，支付与订单状态不同步。

单据分离的代价是多几张表，收益是能表达真实业务里那些不那么规整的情形。

引用关系怎么建

关系应该单向清晰，避免互相引用：

1. 支付单上记录订单号，指向所属订单；
2. 物流单上记录订单号，指向所属订单；
3. 订单本身不直接记录支付与物流细节。

这样安排之后，从订单出发能找到所有关联单据，而各单据之间互不牵扯，单独变更不会互相影响。

三种场景下的变化

排障时的用法

三类单据分清楚之后，定位问题会快很多：

• 用户说付了钱但订单没变——查支付单状态；
• 用户说没收到货——查物流单轨迹；
• 用户对金额有疑问——回到订单明细。

每一种问题对应一类单据，不需要在混合数据里翻找。这就是分离设计最直接的回报。

单据编号的命名

三类单据各有编号，命名上建议保持可辨识：

• 不同类型使用不同前缀，一眼能分清；
• 编号中不编码易变的业务信息；
• 长度足够支撑业务增长，避免后期扩容。

售后单据的延伸

售后不是改一下订单状态就结束，它通常会产生自己的单据：

• 退换货单：记录退回与换出的明细；
• 退款单：对应资金反向动作；
• 退件物流单：对应实物的回程。

这些单据同样指向原订单，关系结构与正向单据保持一致，查询时才不会出现两套逻辑。

三类单据的状态机

三个状态机各自独立推进，但通过订单号保持关联。这种设计让每一类单据都能单独演化，而不会互相牵制。

单据归档与查询

单据量会随时间增长，查询性能与存储成本都需要提前考虑。

• 近期数据保留在主表，支持实时查询；
• 历史数据按时间归档，查询时走归档通道；
• 归档不应改变数据结构，避免出现两套查询逻辑。