管理员把订单改为“处理中”，刷新后正常，过几分钟又回到“待付款”。表面看是后台没有保存，实际更多是另一个流程随后保存了订单。Magento 2 的 state 表示业务阶段，status 是该阶段下展示给运营人员的标签；两者可以映射，但不能任意组合。

先读取订单与历史时间线

SELECT entity_id, increment_id, state, status, updated_at,
       total_paid, total_due
FROM sales_order
WHERE increment_id = '000000123';

SELECT created_at, status, is_customer_notified, comment
FROM sales_order_status_history
WHERE parent_id = 123
ORDER BY created_at DESC;

历史表只记录通过正常业务代码添加的 comment/status，不保证捕获所有直接赋值。若状态变化没有历史，重点搜索直接调用 setState、setStatus 后保存订单的扩展，以及外部 SQL。

支付流程会根据交易结果推进订单

异步支付通常先创建 pending_payment 订单，Webhook 到达后捕获并进入 processing；超时或失败回调又可能取消。测试平台重复推送、事件乱序或商户号映射错误，会把旧事件应用到新状态。对照支付 transaction ID、Webhook event ID、平台发生时间和 Magento 接收时间，不能只按到达顺序处理。

状态改变后又回退，尤其要检查回调是否具有幂等和单调性：已 capture 的订单不应被较早的 authorization pending 事件覆盖。

Cron 与 ERP 同步可能使用旧快照

同步任务在开始时加载订单，处理几分钟后用旧对象整体 save，会覆盖期间由管理员或支付模块更新的字段。应只写确实由该系统负责的字段，保存前重新加载并检查版本/当前状态。外部 ERP 也需要明确 Magento 与 ERP 谁是状态主系统，避免双向循环。

找出代码入口

搜索自定义模块中的订单保存 observer、plugin、repository save 和 resource model save；按订单 ID 增加临时结构化日志，记录调用来源、旧 state/status、新值和 correlation ID。不要长期记录完整订单对象，其中可能包含客户信息。

$logger->info('order_status_change', [
    'order_id' => (int)$order->getEntityId(),
    'from' => $order->getOrigData('status'),
    'to' => $order->getStatus(),
    'source' => 'vendor_webhook'
]);

不要靠锁死状态解决

around plugin 阻止所有状态改变，会让发票、发货、退款等合法流程失效。正确做法是定义允许转换、事件优先级和负责系统。修复后用乱序 Webhook、重复事件、管理员手工修改与 ERP 并发四种场景验证，订单历史应能解释每一次变化。

同时检查前台展示用的是 state 还是 status label。修复写入竞争后，如果主题按 state 硬编码中文而后台按 status 显示，客户和客服仍会看到不同结果。状态映射、邮件文案和 API 输出应使用同一业务定义。