限流处理
如何处理 Twitter API rate limit，避免监测任务悄悄出现覆盖缺口
当限流开始制造 coverage gap 时，它就不再只是日志里的错误，而是工作流设计问题。稳的 Twitter / X 任务，会把 rate limit 当作调度和规划输入，而不是临时事故。
1. 先分清哪些调用是必须的，哪些是可选的
很多流程浪费请求预算，是因为每次 run 都把所有 enrichment 一起拉了。实际里，往往只有一部分调用对 alert 或监测核心路径真的重要。
先把必须采集和可以稍后补充的部分拆开。
- 把 alert-critical 调用单独标出来。
- 能延后 enrichment 的，放到第二阶段。
- 把每条 workflow 的请求预算显式写出来。
2. 让调度频率和预算匹配
如果任务排得太勤，就算每次请求都合法，最后也会慢慢变成不可靠覆盖。
更稳的方式通常是让频率匹配请求预算，以及这类信号真正需要多快被处理。
- critical job 和低优先级 job 用不同 cadence。
- 不要默认让 search、lookup、timeline 用同一频率。
- 把当前 cadence 为什么够用写清楚。
3. 降级运行通常比整条任务失败更好
当出现 rate pressure 时，很多 workflow 更适合先返回核心 search 结果，再把部分 enrichment 延后，而不是整条任务直接失败。
这样能保持 monitoring 可用，同时把缺口显式记录下来。
- 为 rate-limited run 保留 fallback mode。
- 记录哪些 enrichment 被跳过了。
- 在 run record 里明确部分覆盖状态。
4. 把 rate pressure 写进任务记录
团队只有看得到限流压力多常发生、卡在哪一阶段，才知道该改 schedule、scope 还是 workflow priority。
很多时候，一条很小的 rate-limit note 就已经足够帮助后续维护。
- 按 run 保存 rate-limit 事件。
- 记录最先碰到压力的是哪一阶段。
- 在继续加任务前先复盘重复出现的压力。
接口已经能跑，但流程还不稳时，团队通常会问这些问题
这些问题通常会在团队开始重复运行同一条 Twitter / X 任务之后出现。
每次碰到限流都应该立刻重试吗？
通常不该。更好的第一步是决定这次 run 应该等待、降级运行，还是推迟到低优先级阶段。
真正的解决办法一定是买更高额度吗？
不一定。很多流程通过收紧 schedule、减少低价值调用、提高核心路径优先级，就能明显改善。
什么会让限流对实际流程伤害更小？
清楚的阶段优先级，以及 run record 里明确写出跳过了什么、为什么跳过。
这一环通常会一起看的页面
如果下一步是设计等待和重试策略，可以继续看这页。
如果真正根因是 cadence 设计，可以继续看这页。
如果限流只是更大错误策略的一部分，可以继续看这页。
如果 workflow 规模和请求预算已经需要重新看套餐，可以继续看这里。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。