2、订单基础概念：订单类型与订单状态机

订单是电商与供应链系统的核心业务实体，它记录了买家与卖家之间从交易意向达成到履约完成的全链路信息。在实际业务中，订单并非一个简单的“购买记录”，而是一个承载了商品、价格、支付、物流、售后等多维数据的动态对象。理解订单类型与状态机，是后续学习订单流转、库存扣减、对账结算和售后处理的前提。本章将围绕订单的分类维度、状态定义、流转规则及异常分支展开，帮助学员建立清晰的订单生命周期认知框架。

2.1 订单类型的多维分类体系

订单类型是业务规则差异化的基础。不同类型的订单在库存逻辑、支付方式、发货时效、售后政策上存在显著区别。从系统设计角度，订单类型通常由多个维度组合决定，而非单一标签。

2.1.1 按交易模式分类

2.1.2 按业务来源分类

• 线上订单：来自APP、小程序、Web商城，支付方式多样。
• 线下订单：门店POS、导购代客下单，可能涉及门店库存。
• B2B订单：企业采购，通常有账期、合同价、批量折扣。
• 跨境订单：涉及海关申报、国际物流、税费计算。

2.2 订单状态机定义与流转规则

状态机是订单系统的核心逻辑骨架。它定义了订单从创建到终态的所有合法状态，以及状态之间的迁移条件。一个设计良好的状态机，能够防止非法操作（如未支付就发货）、保证数据一致性，并为售后、对账、报表提供可靠依据。

2.2.1 标准状态定义

2.2.2 状态流转规则

1. 正向流转：待支付 → 已支付 → 已发货 → 已完成。每一步都需要前置条件满足，如支付回调成功、物流单号回传、买家确认收货。
2. 逆向流转：已支付 → 已取消（用户申请退款）；已发货 → 售后中 → 退款完成。逆向流转通常需要审核节点。
3. 超时自动流转：待支付超过30分钟自动取消；已发货超过15天系统自动确认收货（具体时长可配置）。
4. 禁止跳转：待支付不能直接变为已发货；已取消不能回到待支付。状态机必须保证单向性。

2.3 实战场景：预售订单的状态流转

预售订单是状态机应用中最复杂的场景之一，因为它涉及“定金支付”“尾款支付”“发货等待”等多个阶段。以下是一个典型的预售订单全流程拆解：

2.4 常见误区与设计复盘

在订单状态机的实际落地中，团队常犯以下错误，需要特别警惕：

• 误区一：状态字段使用字符串。例如直接存“待支付”“已发货”等中文，导致后续扩展和国际化困难。正确做法是使用数字编码（如10、20、30），通过字典表映射显示名称。
• 误区二：缺少“终态”概念。已取消、退款完成、已完成都应该是终态，终态订单不允许再发生任何状态变更。但很多系统在终态后仍允许修改收货地址，造成数据不一致。
• 误区三：忽略“状态历史”记录。只保存当前状态，不记录状态变更轨迹。一旦出现纠纷（如“我明明付款了，为什么显示未支付”），无法追溯操作日志。必须建立订单状态流水表，记录每次变更的操作人、时间、原因。
• 误区四：状态机与业务流程耦合。将审核、风控等业务逻辑直接写在状态流转代码中，导致状态机难以复用。建议将状态机作为独立服务，通过事件驱动触发业务动作。