先抛出几个核心判断：在原型对象上挂载大体积的动态数组，本质上就是把本应有明确生命周期的数据，强行“焊死”在所有实例共享的静态结构上。这种做法虽然不污染数据内容，但会严重污染内存模型并加剧垃圾回收（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 内存管理的根本逻辑，也是避免原型链污染与性能瓶颈的核心实践。
