技术 · 熟练
无人值守时，等也是一种失败
配额要五小时后重置，你的隔夜任务就该等五小时吗
无人值守的任务有一个不显眼的失效方式：它没报错，它只是还在等。撞上 429、撞上服务重启、撞上「本配额已用完，X 小时后重置」—— 默认行为往往是一直等到能跑为止。设白天跑，等几分钟无所谓；设夜里跑，等到天亮就等于这一轮什么也没做，而且日志里只留下一行「运行中」。这一页给的是三个数：单次最长等多久、整轮总共能等多久、超过之后做什么；以及为什么「结束本轮」比「继续等」更划算。
方法 · 一图看懂
1
列出会「等」的地方 — 429 限流 · 529 过载 · 配额度上限 · 依赖服务重启 · 排队等锁
2
给等待设三个数 — 单次最长等待 · 整轮总等待预算 · 超过之后做什么（结束 / 降级 / 换模型）
3
超过就结束，不要续命 — 结束本轮并留下结构化失败（原因 + 已做到哪一步），交给下一次计划重跑
4
把「等到天亮」算进成本 — 隔夜任务的时间窗是有限的，等掉的那几小时不会回来，也没人会替你发现
5
回来先看失败原因属于哪一类 — 没额度 / 服务忙 / 自己的 bug，三种处置完全不同
原理 · 为什么有效
等待之所以危险，是因为它在监控上长得像「正常工作」。一个卡在等待里的任务，状态是运行中、CPU 是闲的、日志没有错误行 —— 所有自动化告警都不会响。而它损失的不是一次调用，是整个时间窗：夜里那八小时本来只够跑一轮，等掉六小时，这一轮就废了。把等待切成三个数之后，判断变简单了：单次等待决定「这一次要不要继续」，总预算决定「这一夜还要不要继续」，超过之后的动作决定「明天早上你会看到什么」。这也是为什么「结束本轮」通常优于「继续等」：重跑是有成本的，但比「一整夜什么都没发生、也没人知道」便宜得多。真正需要区分的是原因 —— 没额度要等人充值或等重置，服务忙只要退避重试，而自己的 bug 等多久都不会好。
适用场景
适用：夜间 / 周末跑的定时任务 · 批量处理与爬取 · 会在配额边缘反复试探的自动化 · 依赖第三方 API 的流水线。⛔ 不适用：交互式会话（人在旁边，等一会儿是正常的）· 一次性的手工重跑（你自己看得见进度）。⚠️ 前提：任务有「一次运行」的明确边界，否则「结束本轮」无从定义。
自测 · 5 问
你的任务在等的时候，日志里能看出来吗？还是只写「运行中」？
「单次最长等待」和「整轮总等待」这两个数，你设过吗？
撞上配额度上限时，它是一直等到重置，还是结束本轮？
第二天早上你看到的那条记录，能说清「它等到几点、为什么放弃」吗？
最近一个月，有没有一轮是「跑了但什么都没产出」？原因属于哪一类？
怎么上手 · 验证步骤
先只改一个任务。第一步：把它的等待点列出来，每个点后面写「现在等多久」。第二步：给整轮设一个总预算（隔夜任务建议不超过时间窗的三分之一），超过就结束。第三步：规定放弃时写什么 —— 至少三样：卡在哪一步、原因属于哪一类（额度 / 服务 / 自己的 bug）、已经完成了哪些部分。第四步：把「结束」接上下一次计划，而不是让人工去点重跑；否则你会得到一堆「等你发现才重跑」的僵尸任务。
改完之后跑一次「假等待」演练：把配额或依赖手工卡住，看它是否在预定时间内结束、并写出三类原因中的哪一类；再确认下一次计划能接手。演练不通过，说明你的等待预算只写在文档里。