原型挂载大内存数据会导致所有实例共享且无法及时回收，推高老年代占用、增加Full GC频率；应改用实例惰性初始化、模块顶层定义或轻量封装来解耦生命周期。
直接在构造函数的 prototype 上挂载大内存数据（比如大型数组、缓存对象、预计算结构等），会导致这些数据与所有实例共享，且生命周期与构造函数本身绑定——只要有一个实例存在，或构造函数未被释放，原型上的大对象就无法被垃圾回收器标记为可回收。这不仅浪费内存，还可能拖慢 GC 的标记阶段（尤其在分代回收中，大对象易晋升至老年代），引发更长的 Stop-The-World 停顿。
为什么原型上放大数据会干扰 GC
原型对象是所有实例共享的，其存活周期由「是否还有活跃引用」决定。一旦某个实例被长期持有（如全局缓存、事件监听器、闭包捕获），整个 prototype 链（包括上面的大数据）都会被视作“可达”，GC 无法清理。即使你只用一次这个构造函数，只要原型上有 10MB 的静态 lookup 表，它就会一直驻留堆中，推高老年代占用，增加 Full GC 触发概率。
改用实例级按需初始化
把大数据从 prototype 移到实例内部，并延迟到首次使用时才创建：
- 在构造函数内不分配，而是设为
null或undefined； - 通过 getter 或专用方法（如
getCache()）检查并惰性初始化； - 配合 WeakMap 存储实例专属大数据，避免强引用阻碍回收。
用模块作用域替代 prototype 共享
如果数据确实是全局只读、多处复用的（如配置表、字典映射），应剥离出构造函数，放在独立模块顶层：
- 用
const LARGE_MAP = new Map(…)定义在模块文件顶部； - 构造函数内部仅引用它，不挂载到 prototype；
- 这样数据生命周期由模块加载器管理，而非与任意实例耦合，也便于单元测试时 mock 或重置。
对必须共享的数据做轻量封装
若确实需要原型级共享，避免直接挂大对象，转而封装访问逻辑：
- 原型上只放小函数，例如
findInLargeIndex(key)； - 实际大数据由外部单例或静态私有字段承载（ES2022+ 可用
#largeIndex）； - 确保该单例有明确的销毁/重置接口，便于在测试或热更新时主动释放。
本质上，这不是“能不能放”的问题，而是“谁负责它的生命周期”。把大内存数据和实例生命周期解耦，GC 才能准确识别真正的垃圾。不复杂但容易忽略。
