Generator自动执行器不解决分布式“分布”问题，但通过线性化、可中断恢复的控制流，封装请求意图并由执行器统一注入服务发现、重试、熔断、traceId透传等横切逻辑。
Generator 自动执行器本身不直接解决分布式网络请求的“分布”问题，但它能规范跨服务、多阶段、带条件分支的请求控制流——关键在于把异步逻辑线性化、可中断、可恢复、可注入上下文。
核心思路：用 Generator 封装请求意图，用执行器接管调度权
分布式请求常涉及服务发现、重试策略、熔断降级、上下文透传（如 traceId）、错误分类处理等。Generator 不负责实现这些能力，而是提供一个干净的“流程骨架”，让执行器统一注入这些横切逻辑。
- Generator 函数只写业务语义：比如
yield api.getUser(id)、yield api.sendOrder(order, { timeout: 8000 }) - 所有网络细节（超时、重试、鉴权头、traceId 注入）由执行器在调用
next()前/后自动增强 - 执行器可拦截每个
yield返回的 Promise，并包装成带熔断器或限流器的版本
执行器需支持的分布式关键能力
一个面向分布式场景的自动执行器，不能只是递归 next()，而应具备以下扩展点：
-
上下文透传：每次
next(value)调用前，自动将当前 traceId、tenantId、requestId 等注入到 yield 出的 Promise 的 config 对象中 -
错误路由：当某个
yield抛出错误，执行器根据错误类型（如NetworkError、ServiceUnavailable、AuthExpired）决定是重试、跳过、降级还是终止整个流程 -
动态并发控制：对一批并行请求（如
yield Promise.all([api.fetchA(), api.fetchB()]))），执行器可按服务等级协议（SLA）限制其并发数或排队优先级 -
状态快照与恢复：在关键步骤（如支付确认后）自动保存 Generator 当前状态（包括已返回的
value和剩余yield序列），支持故障后从断点续跑
典型结构示例
假设一个跨支付网关、库存中心、通知服务的下单流程：
订单${order.id}已支付
执行器 runDistributed(placeOrderFlow, order) 会：
- 为每个
yield请求自动注入全局traceId和timeout - 对
submitPayment设置最多 3 次指数退避重试 - 对
reserveInventory启用 Hystrix 风格熔断，失败 5 次后自动降级为“异步扣减” - 若
notifyUser超时，不中断主流程，仅记录告警并继续返回成功
为什么比纯 async/await 更适合复杂控制流？
async/await 是扁平的、不可暂停的；Generator 天然支持“中途插入逻辑”：
- 可在任意
yield前后插入审计日志、指标打点、灰度开关判断 - 可基于运行时结果动态跳过后续步骤（
iterator.return()或iterator.throw()） - 便于构建可视化流程编排器：每个
yield是一个可配置节点，执行器是运行时引擎
