批量发布任务误报3平台失败？CDP核验揪出日志、脚本、队列三处问题

批量发布任务误报3平台失败？CDP核验揪出日志、脚本、队列三处问题

凌晨两点，我盯着自动平台发布任务的运行日志，心里一沉：队列头部的两篇待发文章——《DeepSeek 本地部署实战》和《Linux 下 Oracle 快速入门》——跑完"2篇×5平台+CDP核验"的批处理脚本后，被标成了博客园、知乎、头条号三个UI平台发布失败，连完成状态都没更新。按原计划这两篇本该十来分钟自动分发到全部平台，现在却要手动排查。这已经是这个月第三次撞上自动化发布的"误报"了。

先拉完整任务日志看：掘金走API提交成功，CSDN提交完成，但博客园、知乎、头条号这三个靠UI交互的平台全返了 FAIL，既没错误堆栈也没返回码，连子进程的 stderr 都被吞得干干净净。我第一反应是网络波动导致UI平台提交超时，于是重跑了一遍单篇发布测试，三个UI平台都能正常提交——问题出在批处理脚本自己身上，不是平台侧。

这时候我想起之前踩过的坑：这个脚本的判断逻辑是去匹配子进程输出里的"发布成功"关键字，没命中就直接判 FAIL。之前就出过平台侧改了返回提示语、关键字匹配不到、误判失败的情况，这次多半是老毛病又犯了。

这套脚本的坑我们团队早有教训，定下一条铁律："日志不可信，以CDP核验为准"。去年就吃过关键字匹配的亏——某平台把"发布成功"改成"内容已上线"，脚本连续一周把所有UI平台的发布结果都误判了，最后还是靠CDP核验才发现问题。这次我立刻连上本地在线的 Chrome 9222 实例（HTTP状态200正常），用 CDP 协议对两篇文章的标题做只读检索，结果直接推翻了"3平台失败"的结论：两篇文章的五个目标平台（博客园、知乎、头条号、掘金、CSDN）全都能检索到对应内容，发布其实已经全部成功。

顺着结论往回扒脚本逻辑，根因很快浮出来：这次 publish.py 子进程因为网络波动，返回的是"发布完成"而不是预设的"发布成功"，关键字匹配直接失效；再加上脚本把子进程的详细错误输出重定向到了空设备，只留了个 FAIL 标记，才演成这场"假失败"。

比误报更麻烦的，是队列状态漏更。核对队列时我发现，第二篇《Linux 下 Oracle 快速入门》的队列项里，头条号的发布状态是 false，done 字段也是 false。回溯批处理日志才看清：跑CDP核验那会儿，头条号的列表页因为缓存没刷新，脚本漏判了头条号状态，没回写进队列。这要是放着不修，第二天的定时任务会检测到这篇"没完成"，重新分发一次，直接变成重复发文事故。

我马上做了三步修复：先读当前队列完整状态，再用CDP核验到的五个平台链接回填队列对应字段，最后把两篇文章的 done 字段都标成完成，顺手把内部文档对应行缺失的链接也补上，重复发文的口子才算堵死。

这次排查看着是"脚本误报"的小事，实则暴露了自动化任务里三个容易被忽略的坑。第一，日志判断不能依赖固定关键字——平台侧返回提示、状态码说变就变，关键节点必须加实机或接口的兜底核验，不能拿日志返回码当唯一依据。第二，绝对不能吞子进程的错误输出，批处理脚本哪怕为了日志整洁，也不能把 stderr 重定向到空设备，至少打进日志文件，不然出了事连线索都没有。

第三，队列状态要和核验结果强绑定，别只靠脚本返回码更新队列，必须在核验环节确认结果后再回写，否则状态不一致迟早引发重复执行。这三条我已经写进自动化任务的校验规范，之后再没出过同类误报。