基础网关完全瘫痪时，yield应通过“内部try-catch+断线退避”双机制实现可控降级：1.在每个yield点做最小粒度隔离，含健康探针与带退避的fetch封装；2.退避用于暂停yield而非重试，期间持续产出降级态数据；3.yield支持核心、辅助、可缓存数据的多级降级路径；4.熔断状态需跨yield持久化并支持手动重置。
基础网关完全瘫痪时，yield（通常指异步生成器或协程中产出数据的环节）不能简单抛错中断，而应通过“内部 try-catch + 断线退避”双机制实现可控降级：既避免调用链崩溃，又防止重试雪崩，还能维持基本产出能力。
1. 在 yield 点包裹最小粒度的 try-catch
不要把整个异步生成器函数包在一个大 try 里，而应在每个可能触发远程调用的 yield 前后做隔离：
- 每次
yield前，先执行一次轻量级健康探针（如fetch('/health', { method: 'HEAD', cache: 'no-store' })），失败则跳过本次产出 - 若需真实请求，将 fetch 封装为带退避的独立函数，在其内部
try中捕获网络异常，并在catch中立即返回默认值或缓存快照，而非 throw 向上冒泡 - 确保
catch块只做三件事：记录降级日志、更新本地熔断状态、返回兜底数据（如空对象、静态模板、上一轮缓存结果）
2. 断线退避不是重试，而是“暂停 yield”
网关完全瘫痪时，重试毫无意义。此时退避算法的作用是主动抑制产出节奏，而非等待恢复：
- 首次探测失败后，启动指数退避计时器（如
minTimeout=500ms, factor=3, maxTimeout=30s），但不用于重试，而是用于控制下一次yield的最早时间点 - 在退避期间，生成器持续产出降级态数据（例如
{ status: 'degraded', timestamp: Date.now() }），保持流不断、连接不超时 - 退避期满后，不自动重连，而是先发一次探针；仅当探针成功，才恢复常规
yield；否则延长退避周期并升级告警级别
3. yield 本身支持多级降级路径
根据业务优先级，为不同数据类型配置差异化降级策略：
- 核心数据（如用户身份、订单状态）：探针失败即 yield
null或抛出轻量错误（new DegradedError('auth_unavailable')），由消费方决定是否终止流 - 辅助数据（如推荐列表、统计指标）：直接 yield 默认空数组或占位结构，不阻塞主流程
- 可缓存数据（如配置、地域信息）：yield 上次成功响应的深拷贝副本，并标记
stale: true
4. 熔断状态需跨 yield 持久化
单次 yield 的降级不能孤立看待，要让状态在多次调用间延续：
- 使用闭包变量或 WeakMap 存储当前熔断窗口、最近失败次数、上次成功时间戳
- 当连续 3 次探针失败，触发“全链路熔断”，后续所有
yield直接走缓存+退避，跳过任何网络操作 - 熔断期间，允许外部手动调用
resetCircuit()强制恢复，适用于运维人工干预场景
