原型链上的大数组：一个隐蔽的内存冲击波

先给个核心判断：直接在原型对象上挂载一个大体积动态数组，这既不是传统意义上的内存“污染”，也不是安全漏洞那种“污染”，而是一种相当隐蔽但后果严重的内存管理失当。它会导致所有实例共享同一份数据，而且正因为生命周期跟整个原型链绑定得太紧，垃圾回收器（GC）根本看不清楚哪些是真正的垃圾了——最终的结果就是：老年代占用持续升高，Full GC越来越频繁，严重时直接卡顿甚至OOM。说白了，真正要防的，是这种设计带来的隐式强引用和GC失效的连锁反应。

别把大数组放 prototype 上

拿个例子来说：MyClass.prototype.cacheList = new Array(100000)。这写法看起来省事，实则是个坑。这个数组一旦创建，就跟构造函数牢牢绑定；只要有一个 MyClass 实例长期存活——比如被某个闭包捕获了，或者注册成了事件监听器——整个原型链包括这个硕大的数组就永远处于“可达”状态，GC 根本碰不了它。

• 所有实例共用同一份数据，修改会相互影响，除非你每次都刻意做深拷贝。
• 数组内容不会随单个实例销毁而释放，造成内存滞留，就像房间里堆着不用的家具，谁也搬不走。
• V8 里大数组很容易晋升到老年代，一旦进了老年代，触发 Full GC 的代价就高得多了。

改用意例级惰性初始化

解决思路其实不复杂：把大数组从 prototype 移回到实例内部，而且等到真正要用的时候才去创建它。

• 构造函数里先不分配：this._cacheList = null，只是一个占位。
• 通过 getter 或方法按需生成：get cacheList() { return this._cacheList ?? (this._cacheList = buildLargeArray()); }。初次访问才真建数组，后面的访问复用。
• 如果多个方法都需要这份数据，又不想重复计算，WeakMap 是个好工具：const cacheMap = new WeakMap(); cacheMap.set(this, buildLargeArray());。实例销毁时，WeakMap 里的数据自动被回收，干干净净。

全局只读数据，剥离到模块顶层

如果这个数组本身就是静态、只读的，而且多个地方都用，比如城市编码表、HTTP 状态码映射这类东西——那就干脆别让它跟任何构造函数有关系。

• 在模块文件顶部定义：const CITY_LOOKUP = new Map([...]);
• 构造函数里只做引用：this.cityMap = CITY_LOOKUP;
• 数据生命周期由模块管理，不会因为实例创建或销毁而波动，测试时也方便替换或重置。

这样一来，数据的生死跟实例完全脱钩，GC 就能清晰地看到谁该回收、谁不该回收。

必须共享时，做轻量访问封装

极少数场景下，确实需要“共享+可变”，那就不要直接暴露大数组本身。

• prototype 上只放小函数：findCityById(id) { return CITY_LOOKUP.get(id); }
• 真实数据由外部单例承载（ES2022+ 可以用私有字段 #lookupTable）
• 提供明确的重置接口：resetCache()，便于测试或热更新时主动释放。

说到底，关键不在于“能不能挂”，而在于“谁负责它的生与死”。让大内存数据脱离原型链的强绑定，GC 才能看清楚哪些是真正的垃圾，才能顺畅地把它清理掉。这才是内存管理该有的样子。