工具笔记
让 AI 改定时同步：一个来源超时，其他来源照常更新
限制单次请求，并保留本轮之外的旧结果。
资料核验2026.11.12 · Node.js · 小型服务与命令行工具
一个定时任务同时读三个发布源，有一个一直不响应。其余两个其实已经成功，但等待全部完成的界面看不到新内容。先给单次请求一个截止时间，再决定失败的来源怎么呈现。
给 AI 的上下文与边界
准备两个本地端点，一个快速返回 JSON，另一个延迟到超时。要求助手给每个来源独立的截止时间和状态，在汇总时保留失败来源上次结果，别让全局 reject 抹掉成功结果。
为每个来源保留独立结果
在支持的 Node 版本中，可以给 fetch 传入 AbortSignal.timeout(8000)。把超时、非成功状态和解析失败记录为单个来源的错误，其他来源照常写入。保留该来源上次成功的数据，并明确显示检查时间和错误。
验收时让本地测试服务延迟响应，另一个端点立即返回。检查任务能在预期时间内结束，成功的来源仍有新数据。
如果后面还要重试，为整轮任务另定预算，避免多个单次超时累加超过调度间隔。
可以直接照着做的演练
固定 A 在 50 毫秒返回，B 延迟超过预设截止时间。记录 B 旧条目的更新时间。跑完后 A 应换新内容，B 保留旧版本但有新的检查状态。再解除延迟，验证 B 不需人工清缓存就会恢复。
检查生成结果
- 快源新数据进入结果。
- 慢源有明确超时提示并保留旧内容。
- 再跑一轮慢源恢复时能够更新，不需清空缓存。
复查时追问一层
分别测连接阶段和读正文阶段。如果系统允许重试，要给整轮调度预算，防止多个请求的等待累计超过调度间隔。让助手交回实际时间范围和哪些端点被故意模拟。
如果请求已经返回响应头，但正文一直没有读完，仍需要验证请求截止时间覆盖了这个阶段。用本地服务分别延迟响应头和正文，观察报错类型与缓存状态。不要只验证定时任务进程退出，快源的成功记录也应能查到。
