应避免在原型对象上挂载大体积动态数组,因其会导致所有实例共享、内存滞留、老年代占用升高及Full GC频发;正确做法是改用实例级惰性初始化、WeakMap隔离或模块顶层只读定义。
直接在原型对象上挂载大体积动态数组,既不是内存“污染”,也不是安全漏洞意义上的“污染”,而是一种高危的内存管理失当——它会导致所有实例共享该数组,且因生命周期绑定过宽,无法被及时回收,推高老年代占用、加剧 Full GC 频率,严重时引发卡顿甚至 OOM。真正要防的,是这种设计带来的隐式强引用和 GC 失效。
例如:MyClass.prototype.cacheList = new Array(100000) 看似省事,实则危险。这个数组一旦创建,就与构造函数强绑定;只要有一个 MyClass 实例长期存活(比如被闭包捕获、注册为事件监听器),整个 prototype 链包括这个大数组就永远“可达”,GC 无法释放。
把大数组从 prototype 移到实例内部,并延迟到首次使用时才创建:
this._cacheList = null
get cacheList() { return this._cacheList ?? (this._cacheList = buildLargeArray()); }
const cacheMap = new WeakMap(); cacheMap.set(this, buildLargeArray());
如果数组确实是静态、只读、多处复用(如城市编码表、HTTP 状态码映射),就不要让它和任何构造函数扯上关系:
const CITY_LOOKUP = new Map([...]);
this.cityMap = CITY_LOOKUP;
极少数场景真需“共享+可变”,那就避免直接暴露大数组本身:
findCityById(id) { return CITY_LOOKUP.get(id); }
#lookupTable)resetCache(),方便测试或热更新时主动释放关键不在“能不能挂”,而在“谁负责它的生与死”。让大内存数据脱离原型链的强绑定,GC 才能看清真正的垃圾。