动态增删属性不拉长原型链但破坏隐藏类与内联缓存，致属性访问从o(1)退化为多层遍历；应稳结构、用map替代、绑定方法、选null原型。
对象属性动态增删本身不直接拉长原型链，但会严重干扰引擎对原型链查找的优化机制——核心破坏点在于隐藏类（Hidden Class）退化与内联缓存（IC）失效，最终让本该接近 O(1) 的属性访问退化为多层线性遍历。
隐藏类结构被打破，原型查找失去“快路径”
现代引擎（如 V8）依赖稳定的对象结构生成隐藏类。一旦在运行时执行 delete obj.x 或 obj.y = newValue（尤其新增非初始结构的属性），引擎会： - 触发隐藏类切换（transition），原 IC 记录作废 - 若对象已进入“慢属性模式”（dictionary mode），后续所有属性访问（包括原型链上的）都绕过偏移计算，改用哈希表或线性扫描 - 原型链查找被迫放弃结构化跳转，退回到逐层 __proto__ 解引用 + 属性表比对的完整流程
内联缓存（IC）频繁 miss，高频访问代价陡增
IC 通常只缓存前 1–2 层原型的查找结果。当对象结构不稳定时： - 引擎无法确认下一次访问是否还走相同路径，IC 直接标记为“未初始化”或“多态” - 每次 obj.method() 或 obj.status 都要重新执行完整查找：自身查表 → 跳 __proto__ → 读目标原型隐藏类 → 校验 IC → 再查表 - 实测显示：结构频繁变更的对象，原型属性访问比稳定对象慢 4–6 倍，动画帧中易引发掉帧
动态增删常伴随原型链污染或意外继承
看似无关的操作可能悄悄延长查找链： - 使用 Object.assign(target, source) 时，若 source 是原型链较深的对象，其属性会被浅拷贝，但 target.__proto__ 不变；真正危险的是后续误用 for...in 或 hasOwnProperty 判定逻辑，导致本应自有属性被当成原型属性处理 - 给 Object.prototype 或 Array.prototype 动态添加方法（如 Object.prototype.deepClone = ...），会使所有对象的原型链末端多出一层，每次查找失败都要多走一步 - Object.setPrototypeOf(obj, newProto) 在循环中调用，不仅新增一层，还会强制清空整个 IC 表
替代方案：稳结构、缓引用、避污染
不禁止动态操作，但需规避底层开销： - 初始化时尽量一次性定义全部自有属性（哪怕赋 undefined），保持隐藏类稳定 - 需要后期扩展字段时，优先用 Map 存储动态键值，避免污染实例自身结构 - 高频访问的原型方法，在构造函数中显式绑定：this.toString = Parent.prototype.toString - 纯数据容器场景，直接用 Object.create(null) 创建无原型对象，彻底消除查找链
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
