技能介绍

你要排查的问题

WooCommerce 的 webhook 偶尔会静默失败：订单状态变更、库存更新或客户资料修改之后，订阅端始终没收到事件，日志里也没有任何报错。这类问题之所以难查，是因为一次交付的状态分散在三个地方——Action Scheduler 队列里的待办任务、WC_Webhook 对象记录的交付状态、以及 REST 端点的实际响应。任何一个环节出问题，都可能造成事件丢失或重复投递，而排查时要在这三处之间来回对照。

技能如何工作

该技能按以下步骤还原一次 webhook 交付的完整链路：

通过 /wp-json/wc/v3/webhooks 端点拉取所有已注册的 webhook，确认它们的订阅 topic 与投递目标
读取 WC_Webhook 模型的状态字段，检查最近一次交付是成功、失败还是仍处于待处理
扫描 Action Scheduler 队列中滞留或被重试的任务，识别堆积的投递请求
对照订单、产品、客户三类工作流，核对已订阅事件与实际触发事件之间的覆盖缺口
分析重放模式，区分问题来自订阅配置遗漏还是队列执行异常

适用边界与注意点

面向 WooCommerce Monorepo 的开发与诊断场景，假定运行在 POSIX 环境（Linux/macOS）上；Windows 机器需通过 WSL 使用
依赖 PHP 7.4+ 与 Composer，才能执行模型层与端点层的检查
只反映单个实例内的队列与交付状态；跨站点复制、跨集群的 webhook 问题需要额外的外部工具配合