订单状态有哪些：从待付款到签收的全状态字典

"我的订单显示待发货三天了""已发货但物流不更新""退款中的钱什么时候到"——客服每天回答的问题，八成在问订单状态。订单状态是订单系统的公共语言：客户用它看进度、客服用它定位问题、系统用它控制动作（什么状态能改地址、什么状态能取消）——这本字典清楚了，一半的订单疑问不用问人。本文把这本字典写全。

正常状态链：一单的顺时针旅程

状态链的设计逻辑：每个状态对应"下一个动作的责任方"——待发货的责任方是仓库、在途的责任方是承运商、已签收的责任方回到客户。状态停留超过该环节的正常时长，就转化为异常信号：状态本身就是进度监控的传感器，卡状态的单据清单（超时待发货、超时在途）是运营每天该看的第一个报表（状态在系统间的回传机制见本站订单状态回传专题）。

异常与逆向状态：另一本一半的字典

正常链之外，还有一组"岔路状态"：已取消（支付前取消、支付后拦截成功——拦截的机制见本站订单拦截专题）；退款中/部分退款（售后审核通过，等待退款执行）；退款成功（资金退回完成——注意"退款中"到"退款成功"之间是支付渠道的处理时长，与商家无关的部分要给客户讲清）；退货中/已退货（客户寄回，待仓库收货质检）；换货中（旧件与新件的两次物流）；交易关闭（取消或退款完成后的终态）。异常状态的管理要点是时限与责任：每个异常状态定义处理时限（退款审核四十八小时内）与升级路径（超时自动升级），客户对异常的容忍度取决于处理速度而不是异常本身。

客户视角的常见困惑与标准解释

待发货很久——支付高峰或大促期的仓库积压，正常阈值内是排队、超阈值是异常（该催仓库或看拦截）；已发货但轨迹不动——承运商揽收扫描到分拨中心之间常有静默期（尤其旺季），超过七十二小时无更新该走查单；签收但没收到——代收点、驿站、家人代签的可能，先查签收底单再找承运商；已完成但有问题——完成不等于不能售后（售后窗口按平台规则独立计算）。

企业侧：状态体系的设计与治理

自建商城或多渠道零售的企业，状态体系的设计原则：客户可见状态与内部状态分层（内部有十八个状态，客户看到七个就够——拣货中、打包中对客户都是"备货中"）；状态机化管理（状态的流转规则固化——什么状态能取消、能改址，规则之外的操作走审批）；多渠道状态口径统一（自营、平台、线下订单的状态映射表，客服与报表用同一套话术与口径）。状态治理的价值在数据侧兑现：状态停留时长按环节统计，就是全链路的时效体检表——哪个环节的停留中位数在恶化，产能与协作的问题就出在哪（订单全链路的协同机制见本站OMS与WMS协同专题）。

常见问题

已发货状态是谁写的，能人工改吗

标准做法由系统事件驱动：WMS出库回传或承运商揽收扫描写入，不是人工点按钮。人工改状态（把没发的标成已发）是虚假发货，平台规则与消费者权益的红线——发货状态必须与真实交接对应。

订单状态和物流状态是一回事吗

不是：订单状态是商家侧的全流程（含支付、售后），物流状态是承运商侧的运输段（揽收到签收）。两者关联但不等同——订单"已发货"后，物流状态才接棒更新；售后阶段的订单状态（退款中）物流状态里没有。客服排查时先分清问的是哪一层，一半的"状态不对"是两层混着看。

为什么各平台的订单状态叫法不一样

各平台有自己的状态模型（待发货/待揽收/运输中/交易成功……），做全渠道生意的企业要建状态映射层：把各平台状态归一到内部统一口径，报表与客服才不会各说各话——这是OMS的基础能力之一（多渠道订单的统一管理见本站全渠道订单专题）。