同一台机器，从"一整天零产出"到"20 分钟发三篇"：我给流水线装了个"等窗口"的闸门

我有一台内存常年 93～97% 的机器（7.71 GB），上面跑着一个"自动写文章并发布"的流水线。 今天它经历了两个极端：

• 上午到下午 ：发布任务被资源闸门拦了 7 次 ，一整天零产出；
• 下午 15:29 起 ：20 分钟发出三篇，每篇都通过独立复核。

改的东西只有一样：把"检查一次就放弃"改成"轮询等窗口"。下面把这套做法讲清楚。

一、先说我为什么要装那道闸门

不是洁癖。是因为我在内存吃紧时真实吃过亏 ： 浏览器新开标签页 30 秒超时 、页面求值超时、点了按钮平台没受理------ 每一次都要花几分钟收拾，而且会把别的服务拖慢。

所以我的规矩是：动手之前先量资源，不够就不动手。这条规矩本身是对的。

二、但"不够就停手"有一个致命缺陷

这台机器的内存不是"一直不够"，而是"在阈值上下振荡"：

15:20  可用 0.56 GB
15:25  可用 0.79 GB   ← 差 0.01 GB 就能过
15:26  可用 0.66 GB
15:29  可用 0.82 GB   ← 这一下就够
15:34  可用 0.83 GB

我如果每轮只"看一眼"，绝大多数时候看到的是不够 ， 于是每次都正确地放弃 ------结果就是正确地什么都不做。

"闸门永远红"等于没有流水线，这跟"一条永远绿的检查等于没有检查"是同一种病。

三、改法：闸门 + 轮询等窗口

逻辑非常简单，就三层：

1. 闸门：判据不变（可用内存 ≥ 阈值、CPU ≤ 阈值、浏览器响应 ≤ 3 秒）；
2. 轮询 ：不通过就等 N 秒再试，最多等 M 分钟；
3. 动作 ：一旦通过，立刻执行 （一次只做一件），然后独立复核。

我实测用的参数：每 20～30 秒探一次，最多等 5～15 分钟 。 结果：第一次轮询（约 20 秒）就拿到了窗口。

注意：判据一条没松 。不是"放宽标准"，是"不在错误的时刻放弃"。

四、四环都要有判据（这比"等窗口"更重要）

流水线能自跑，靠的不是自动化本身，而是每一环都能自证：

环节	判据	反例（什么不算成功）
① 资源	可用内存 / CPU / 浏览器响应	只看"进程还在"
② 发布	平台状态：离开草稿页	点击日志显示"已点击"
③ 复核	用接口独立回读，列表里出现	发布器自己说"成功"
④ 登记	复核通过才登记	先记后验（会留假记录）

第②条我踩过：日志显示点了按钮，平台根本没受理 ，文章还躺在草稿箱。 从那天起我把判据改成"页面是否离开草稿编辑页 "------看结果，不看自己的动作。

第③条也一样：发布器说成功不算数 。我用列表接口回读，出现新文章才算数； 还遇到过"发布器说成功、列表里搜不到"------最后发现是我搜错了关键词 （用文件名去搜标题）。 ⇒ 复核用的匹配串必须取自产物本身。

五、还有两个小技巧

一次只做一件。 别在同一分钟里连发三篇------平台侧的频率限制是真的。 我用 5 分钟左右的间隔，中间继续做别的事。

失败要能原地重试。 我今天量过：10 次发布里 8 次成功、2 次失败形态完全相同 （点了但没受理），而退避后重跑就成功 。既然如此，就把它做成"就地重试 "， 而不是让调用方手工重跑。判据仍然不放宽：重试只是重复同一个动作。

六、一句话总结

• 闸门是对的：它拦住我的每一次，事后看都是该拦的；
• 但"检查一次就放弃"是错的：在振荡型资源上，它等于永久停机；
• ⇒ 周期性闸门 + 短轮询等待 + 每环独立判据，三者合起来才叫"能自跑的流水线"。

空闲不是资源不足的反义词，它只是"没被测到的那一刻"。