Cron锁提前失效造成重复任务：给财务的一页说明

先用一句话说清财务看到的异常

本次费用重复的直接原因，是库存同步任务尚未结束时互斥锁已经过期，后续调度又启动了同一任务。三次运行都来自内部的inventory-sync后台作业，没有证据显示访客或外部自动化工具触发了这些调用。

给财务的说明不要从WordPress钩子名称开始。先列受影响日期、重复调用数量、估算金额和是否影响客户，再附技术证据。这样审批人可以先判断财务重要性，工程团队也不会把尚未确认的费用写成最终账单。

11分钟任务与5分钟锁为何必然重叠

历史数据表明该任务p95运行11分钟，但锁的存活时间只有5分钟。第一项任务仍在执行时，第5分钟锁即失效；下一次调度认为无人占用，于是启动第二项。若第三次调度再次遇到过期锁，就会形成三个重叠运行实例。

这不是说每次都会恰好产生三倍费用。需要用运行编号、开始结束时间、处理对象和供应商请求编号确认每个实例完成了哪些工作。只有同一业务批次被多个运行实例实际提交，才能计入重复费用。

为什么流量分类在这里不适用

Human、Bot和Unknown用于描述进入站点的请求证据，而此次调用由已知后台调度器在服务器内部发起。给inventory-sync强行贴上Bot标签会混淆两个问题：谁访问了网站，以及哪个内部任务重复执行。

错误的封禁还可能影响真正客户，却无法阻止Cron下一次启动。财务需要看到的是来源可归属、重复范围可计算、修复有负责人，而不是一个听起来安全但与根因无关的分类名称。

控制方案要同时防重叠与防卡死

第一项修复是让锁覆盖合理的最长运行时间，并在任务执行期间安全续租；第二项是给每个业务批次增加幂等标识，即使锁异常也不重复提交付费工作。仅把锁改为无限期，会在进程崩溃后留下永久阻塞，因此还需要超时接管和人工解除流程。

上线前用超过11分钟的测试任务验证续租，再故意终止一个进程验证接管。验收条件包括同批次最多一个付费运行、失败后可以恢复、锁状态可观察，以及重复费用不再增长。

一页说明应以可复核的承诺收尾

最终文档写明：已确认原因、尚待供应商账单确认的金额、临时控制、永久修复、验证日期和责任人。不要承诺绝不再发生；应承诺用哪些指标发现复发，以及超过什么门槛会暂停任务。更多类似事件的诊断文章可从博客继续查阅。

保留说明版本和底层运行记录的链接，但限制日志访问权限。财务只需看到支持结论的最小证据，工程团队则保留足够细节复测，二者不必共享含用户数据或密钥的完整日志。

把“Cron锁提前失效造成重复任务：给财务的一页说明”的一页原因与控制说明用于第一次真实安装。免费下载 AI Cost Circuit Breaker，先从 Monitoring 开始，验证预期信号和回退方式后再启用强制控制。