自定义订单状态不会天然具备原有状态的全部邮件、库存和第三方集成行为。新增前应明确其业务含义及进入退出条件，再核对通知触发、统计与履约，不能只让后台出现一个新标签。
先定义新状态解决什么问题
说明“待复核”与待付款、处理中等已有状态有何区别，谁可设置、何时进入及怎样退出。若只是内部标记，可能有更合适的备注或字段方式。不要为每个临时情况创建状态，导致销售和系统无法判断订单是否可发货。
列清依赖原状态的动作
邮件、库存、下载权限、物流和外部ERP可能都按特定状态触发。将订单移到自定义状态后，默认通知未必自动处理，不能复制一个颜色就认为流程继承。不同扩展的支持方式需要按当前官方或开发文档核对，避免直接改核心文件。
安排受控迁移与回退
在测试环境创建样本，记录从各已有状态进入新状态以及回到正常流程的结果。保护正在进行的真实订单，不批量把历史订单重写成新状态。若撤销扩展，也要提前规划遗留订单状态和资料读取，不留下无法识别的记录。
检查客户和后台两种视角
核对客户订单页名称、邮件文案与管理员操作，确认新状态不暗示已经付款或发货。再检查统计、导出及集成，验证必要动作只执行一次。通知是否发送和客户实际收到分别记录，不把新状态保存成功当成流程交付完成。
关键区别
状态标签：描述业务阶段；不是完整工作流实现。
触发动作：邮件库存与履约；按具体状态机制核对。
客户说明：表达真实进度；不得暗示未发生的付款。
怎样确认处理到位
新状态可按约定进入和退出，客户文案准确，必要邮件、库存及集成动作正确且不重复，历史订单与统计有可解释处理方式。
容易误判的边界
本篇不提供直接修改WooCommerce核心状态代码的通用片段。自定义工作流应有维护责任和版本测试，不只满足后台“能选新状态”。
