闭包私有状态导致每个实例独占作用域对象，内存开销大且GC困难；类私有字段（#field）共享隐藏类结构，内存更紧凑、回收更高效。
闭包私有状态的内存分配特点
闭包实现私有状态时，每个实例都会生成独立的作用域对象（如 V8 中的 Context），它持有所有被捕获的变量引用。即使只用一个私有字段，整个外层函数作用域中所有变量（包括未使用的）都可能被保留在内存中。
常见错误是误以为“只捕获需要的变量”就能节省内存——实际上 JavaScript 引擎（如 V8）在优化阶段未必能精确剔除未使用变量，尤其当存在动态访问（eval、with、arguments）或调试器激活时，整个词法环境会被保守保留。
- 每次调用工厂函数（如
createCounter()）都会创建新闭包，不可复用作用域对象 - 私有变量无法被 GC 回收，除非闭包本身被完全断引用（包括事件监听器、定时器等隐式引用）
- Chrome DevTools 的
Memory > Allocation instrumentation on timeline可观察到大量重复的Closure实例
类实例私有字段的内存布局更紧凑
ES2022 的 #field 语法让私有字段真正绑定到实例对象本身，不依赖外层作用域。V8 将其编译为与公有属性类似但带访问控制的内部槽位（internal slot），共享构造函数的隐藏类（hidden class）结构。
这意味着：多个实例可共享内存布局描述，仅数据存储分离；且私有字段不会拖拽无关变量进内存图谱。
-
#count和this.count在 V8 中占用几乎相同的内存（约 8 字节基础开销 + 值存储） - 类继承链中，私有字段仍保持隔离，但隐藏类仍可优化（只要字段声明顺序和数量一致）
- 对比闭包，类实例在
Heap Snapshot中表现为标准Object，无额外Closure节点
实测差异：10 万个实例下的典型表现
在 Node.js 20+ 或 Chrome 120+ 环境下，运行以下对比：
function makeClosure() {
let _value = 0;
return {
inc: () => ++_value,
get: () => _value
};
}
class Counter {
#value = 0;
inc() { return ++this.#value; }
get() { return this.#value; }
}
结果不是“闭包慢”或“类快”，而是：闭包版本的堆内存峰值高约 15–25%，主要来自重复的上下文对象；而类版本的 GC 停顿更短、更规律，因对象结构更可预测。
- 闭包版在
heapUsed中多出约 3–4 MB（取决于引擎版本） - 若闭包内含大对象（如缓存数组），该对象会被所有闭包实例间接引用，放大泄漏风险
- 类版启用
--trace-gc可见更少的 Scavenge 次数，因新生代对象更“干净”
选择依据不能只看内存数字
真实项目里，闭包和类的性能差异常被 I/O、渲染或算法复杂度掩盖。真正影响决策的是：是否需要动态生成行为、是否要兼容旧环境、是否需对私有状态做反射或序列化。
- 若需模块级单例私有状态（如配置缓存），闭包更自然；类反而要靠
static #config补救 - 若私有状态需被
JSON.stringify排除，两者都得手动处理（toJSON或Symbol.toStringTag） - V8 对
#field的优化仍在演进——某些场景（如极深嵌套访问）可能暂时不如闭包直接读取快，但差距在缩小
别为了省几十 KB 内存强行改写逻辑；但若你在写高频创建的工具类（比如事件总线订阅器、AST 节点包装器），优先用 #field 是更稳妥的选择。
