构造函数不能使用 function* 或 yield，因其必须同步返回实例；应将 generator 逻辑抽离为静态方法、实现 symbol.iterator 或结合 async generator 懒初始化，明确构造与产出的职责分离。
普通类的构造函数中确实不能直接使用 function* 或 yield，这不是语法错误，而是语言设计限制：构造函数必须同步返回实例，而 Generator 函数返回的是迭代器对象，不是实例本身。所谓“现代化架构设计断层”，本质是同步初始化语义与异步/分段执行能力之间的不匹配。解决思路不是绕过限制，而是把 Generator 的能力用在它该在的位置。
用静态 Generator 方法替代构造时 yield
把需要分段产出或懒加载的逻辑，抽离为类的静态 Generator 方法，由外部按需消费：
- 例如，一个数据处理器类不在线上构造时拉取全部数据，而是提供
static* fetchDataIterator()方法 - 实例创建保持轻量、同步、可预测；耗时或分阶段行为交给独立的 Generator 方法
- 调用方可用
for...of、Array.from(it)或手动next()控制节奏
构造后立即返回可迭代实例（封装 Generator）
让类自身实现 [Symbol.iterator]，内部委托给一个私有 Generator 函数：
- 构造函数不做 yield，但初始化一个 Generator 函数引用（如
this._gen = this.#createIterator()） - 定义
[Symbol.iterator]() { return this._gen(); }，这样实例天然可遍历 - 既保持构造同步，又对外暴露 Generator 行为，符合迭代器协议
组合式替代：用 async generator + 懒初始化代理
当需要异步分段能力时，优先考虑 async function*，并配合延迟初始化模式：
- 构造函数只存配置或连接句柄，不触发实际流程
- 提供
async *streamRecords()等方法，内部用await+yield - 配合
ReadableStream或自定义流包装器，对接现代 Web API（如 Fetch、TransformStream）
避免误用：别把 Generator 当构造逻辑搬运工
Generator 不是“异步构造函数”的替代品。常见误区包括：
- 试图在 constructor 里
yield—— 语法报错，且违背实例化契约 - 用 Generator 包裹整个初始化过程再
next()模拟构造 —— 增加调用方心智负担 - 混淆
return和yield的语义：构造必须返回this，Generator 返回迭代器
关键不在规避限制，而在厘清职责：构造负责创建，Generator 负责产出。两者协同，而非合并。
