超时值是分布式调用中保障系统稳定性与用户体验的第一道防线。它防止雪崩、提升响应可预期性、驱动降级与可观测性，并需匹配业务SLA而非技术惯性。
在分布式调用中，get(timeout) 是阻塞式获取异步任务结果的关键操作，其超时值不是“可选配置”，而是系统响应力的硬性边界。它直接决定用户是否看到空白页、前端是否触发重试、下游服务是否会因等待而堆积线程——一句话：超时不是兜底策略，而是第一道防线。
防止调用链路雪崩
当一个服务 A 调用服务 B 的异步任务，并用 get(30) 等待 30 秒，而 B 实际卡在数据库锁或下游依赖上，A 的线程/协程将被持续占用。若并发量上升，A 的连接池、线程池迅速耗尽，继而无法响应其他请求，故障沿调用链向上蔓延。合理设置 timeout（例如 5 秒）能快速释放资源，避免单点延迟拖垮整条链路。
保障用户体验可预期
用户不关心后端是“正在处理”还是“卡住了”，只感知“没反应”。前端发起异步任务后，若后端 get(timeout) 设置过长（如 60 秒），用户可能等待半分钟才看到错误；若设为 3 秒，则可在 3 秒内返回“处理中，请稍后查看”或跳转轮询页面，体验更可控。Dify 中常见工作流回调失败，往往就源于后端 get() 等待太久，前端已放弃轮询。
驱动系统主动降级与可观测性
get(timeout) 超时抛出异常，是触发降级逻辑的明确信号：
- 立即返回缓存结果或默认值
- 记录超时事件并上报 Prometheus 指标（如 task_timeout_rate）
- 自动告警，提示运维检查对应 Worker 负载或模型推理延迟
没有这个超时出口，系统只能被动等待、静默失败，问题难以定位。
匹配真实业务 SLA，而非技术惯性
很多团队把 get(60) 当成默认值，但业务未必需要等那么久。例如：
- 短信发送类任务：5 秒超时足够，超时即走备用通道
- 大模型摘要生成：用户可接受 15 秒等待，设为 20 秒留缓冲
- 批量数据同步：不应用
get()阻塞等待，而应改用任务 ID + 轮询 API
超时值必须对齐业务容忍度，而非“反正服务器能扛住”。Dify 的 task_execution_timeout=120s 是后台执行上限，前端调用方的 get() 应远小于此值（建议 ≤30s），形成分层防御。
