如何评估闭包与类在实现私有状态时的内存性能差异
简单来说，闭包私有状态导致每个实例独占作用域对象，内存开销大且GC困难；而类私有字段（#field）共享隐藏类结构，内存更紧凑、回收更高效。下面我们来拆解这背后的原因。
闭包私有状态的内存分配特点
当使用闭包来实现私有状态时，每个实例都会生成一个独立的作用域对象（在V8引擎中称为 Context），这个对象持有着所有被捕获变量的引用。这里有个常见的误区：你以为只捕获需要的变量就能节省内存？实际情况可能更复杂。Ja vaScript引擎（比如V8）在优化阶段未必能精确剔除那些未使用的变量，特别是当代码中存在动态访问（如eval、with）或者调试器被激活时，整个词法环境往往会被保守地保留下来。
- 每次调用工厂函数（例如
createCounter()）都会创建一个全新的闭包，其作用域对象无法被复用。 - 私有变量无法被垃圾回收（GC）回收，除非闭包本身被完全切断引用——这包括那些容易被忽略的隐式引用，比如事件监听器或定时器。
- 在Chrome DevTools的
Memory > Allocation instrumentation on timeline工具中，你可以直观地观察到大量重复的Closure实例。
类实例私有字段的内存布局更紧凑
ES2022引入的 #field 语法则走了另一条路。私有字段被真正绑定到了实例对象本身，不再依赖外层作用域。V8引擎将其编译为带有访问控制的内部槽位（internal slot），并与公有属性一样，共享构造函数的隐藏类（hidden class）结构。
这意味着什么？多个实例可以共享同一套内存布局描述，只有存储的数据是分开的。更重要的是，私有字段不会把无关的变量拖进内存图谱里。
- 在V8中，
#count和this.count占用的内存几乎相同（大约是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标志后，可以观察到更少的Sca venge（新生代回收）次数，这是因为新生代中的对象结构更“干净”。
选择依据不能只看内存数字
在真实项目中，闭包和类之间的性能差异，常常会被I/O操作、渲染任务或算法复杂度所掩盖。真正影响技术选型的，往往是这些因素：是否需要动态生成行为？是否需要兼容旧环境？是否需要对私有状态进行反射或序列化？
- 如果需要模块级的单例私有状态（例如配置缓存），闭包的写法反而更自然；用类来实现，可能还需要借助
static #config来补救。 - 如果私有状态需要被
JSON.stringify自动排除，那么两者都需要手动处理（通过定义toJSON方法或使用Symbol.toStringTag）。 - V8引擎对
#field的优化仍在持续演进。在某些特定场景下（比如极深嵌套的属性访问），它可能暂时不如闭包直接读取变量快，但这种差距正在逐渐缩小。
所以，结论是：不必为了节省几十KB的内存而强行改写清晰的业务逻辑。但是，如果你正在编写需要高频创建实例的工具类（比如事件总线的订阅器、AST语法树的节点包装器），那么优先使用 #field 无疑是更稳妥、更具前瞻性的选择。
