Generator函数暂停恢复时保留作用域，核心在于引擎为其维护独立执行上下文，包含词法环境、变量环境及父级作用域引用，并完整快照状态而非依赖闭包。
Generator 函数暂停和恢复时能保留作用域，核心在于它内部维护了一个**独立的执行上下文（execution context）**，该上下文包含词法环境（LexicalEnvironment）、变量环境（VariableEnvironment）以及对父级作用域的引用。这不是靠闭包“模拟”的，而是 V8（及其他引擎）在实现 generator 时，将整个函数调用的状态（包括作用域链、变量值、暂停点）完整封存为一个可恢复的对象。
generator 执行状态被完整快照保存
每次调用 gen()，引擎会创建一个 generator 对象，并为其分配专属的执行上下文。这个上下文不会像普通函数调用那样在 return 后被销毁，而是在 yield 暂停时被冻结：
- 当前作用域中所有局部变量（
let、const、var）的值被保留在内存中 - 词法环境链（指向外层函数/全局环境）保持不变
- 执行指针（如哪一行代码被 yield 中断）也被记录
例如：
function* counter() {
let count = 0; // ✅ 暂停时仍存在
const id = Math.random(); // ✅ 值不会重计算
while (true) {
yield count++;
}
}
<p>const it = counter();
console.log(it.next().value); // 0 → count=0, id 已生成
console.log(it.next().value); // 1 → count=1, id 还是同一个
</p>作用域链不因暂停而断裂
generator 内部可以自由访问其定义时的外层变量（闭包行为），且该访问能力在多次 next() 调用中始终有效：
- 函数声明时确定的词法作用域，在 generator 实例化时就被绑定到其执行上下文中
- 即使外层函数早已返回，generator 仍持有对外层变量的引用（只要它没被 GC）
- 多个 generator 实例互不影响，各自拥有独立的作用域副本
比如：
function createAdder(x) {
return function*() {
let y = 0;
while (true) yield x + y++; // ✅ x 来自外层 createAdder，y 是自身局部
};
}
<p>const add5 = createAdder(5)();
console.log(add5.next().value); // 5
console.log(add5.next().value); // 6 → x 仍是 5，y 已变成 1
</p>引擎层面：generator 对象封装了执行上下文
ECMAScript 规范将 generator 定义为具有 [[GeneratorState]] 和 [[GeneratorContext]] 的对象。其中 [[GeneratorContext]] 就是那个被挂起的执行上下文，它明确包含：
-
LexicalEnvironment：当前作用域及所有外层作用域的链表 -
VariableEnvironment：用于var变量提升的环境（通常与 LexicalEnvironment 相同） -
CodeEvaluationState：记录当前执行位置（如字节码偏移或 AST 节点）
每次调用 next()，引擎不是重新执行函数，而是恢复这个上下文并从中断处继续运行——所以变量没重初始化，作用域没重建。
注意：不是“闭包”在起作用，而是执行上下文持久化
容易误解为“因为 generator 是闭包，所以能记住变量”。其实闭包只是让函数能访问外层变量，但普通函数执行完上下文就销毁了；generator 的特殊性在于：它的执行上下文被显式挂起并长期驻留内存。你可以把它理解为一个“可序列化的栈帧”，暂停时写入内存，恢复时读回 CPU 寄存器和堆栈。
这也解释了为什么 generator 不支持跨线程传递（无法序列化上下文），以及为什么长时间不调用可能导致内存泄漏（作用域链中的对象无法被回收）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
