防止原型对象挂载大动态数组导致内存污染

先抛出几个核心判断：在原型对象上挂载大体积的动态数组，本质上就是把本应有明确生命周期的数据，强行“焊死”在所有实例共享的静态结构上。这种做法虽然不污染数据内容，但会严重污染内存模型并加剧垃圾回收（GC）的负担。真正需要防范的不是“污染”，而是“不可回收”带来的内存泄漏风险。

直接给出结论：像 MyClass.prototype.cacheList = new Array(100000) 这种写法，会让这个巨型数组伴随构造函数长期驻留在堆内存中。只要有一个实例未被回收，或者构造函数被某个闭包持有，整个原型链（包括这个大数组）就无法被标记为垃圾。这会带来哪些后果？

• 数组本身占用大量连续内存，容易晋升到老年代，直接推高 Full GC 的频率，影响应用性能。
• 所有实例共享同一引用，任何一处的修改都会全局生效，调试时堪称灾难现场。
• 单元测试时无法独立重置状态，跨用例的副作用让你防不胜防，增加维护成本。

改用实例级惰性初始化

解决方案其实很直接：将大数组从 prototype 上剥离，转移到实例内部，并延迟到首次使用时才创建。具体如何操作？

• 构造函数里只设置 this._cacheList = null 或 undefined，先占个位。
• 使用 getter 封装访问逻辑：get cacheList() { return this._cacheList ?? (this._cacheList = new Array(100000)); }。这样每次访问才会真正创建数组，避免提前分配。
• 如果需要更强的隔离性，可以用 WeakMap 来存储：外部通过 map 映射实例到数组，避免强引用阻碍垃圾回收。这样每个实例拥有独立的数组，生命周期完全解耦。

全局只读数据请放模块顶层

如果这个数组确实是多处复用、且不可变的（比如预计算的坐标索引表），那么最好把它从构造函数中彻底分离出来：

• 在模块文件顶部直接定义常量：const GLOBAL_COORD_INDEX = new Float32Array(…);
• 构造函数内仅引用该常量：this.index = GLOBAL_COORD_INDEX;
• 这样一来，数据由模块加载器管理生命周期，不与任何实例耦合。不仅便于 mock 测试，也方便热替换或模块更新。

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

如果业务逻辑确实强依赖“所有实例共用同一份可变数组”，也请不要直接把数组挂在原型上。正确的做法是封装一个轻量访问层：

• 原型上只放一个小函数：MyClass.prototype.findInIndex = function(key) { return SharedIndex.get(key); };
• 真正的数组放在外部单例或私有静态字段中（ES2022+ 可以用 #index）。
• 再提供一个明确的销毁接口：SharedIndex.clear()，方便测试清理或运行时重置，避免内存残留。

说到底，关键不是“能不能挂”，而是“谁来决定它什么时候该消失”。把大数组的生命周期从 prototype 上解耦出来，垃圾回收器才能真正看清哪些内存是垃圾、哪些还能复用。这才是 JavaScript 内存管理的根本逻辑，也是避免原型链污染与性能瓶颈的核心实践。