delete操作会不可逆地破坏隐藏类结构承诺，迫使对象进入字典模式，导致内联缓存失效、访问退化为哈希查找、内存激增且无法恢复快属性模式。
删除属性会直接破坏隐藏类的结构承诺，V8 无法维持原有优化路径，对象被迫转入字典模式——这不是临时降级，而是不可逆的性能退化。
delete 触发的不是“切换”，而是“放弃”
V8 的隐藏类本质是结构契约：它保证“这个对象一定有 x、y、z 属性，且顺序固定、类型稳定”。delete obj.x 不是移除一个值，而是宣告契约失效。V8 必须立刻放弃当前隐藏类所支撑的所有优化，包括内联缓存（IC）和快速属性访问路径。
- 对象从“快属性模式”（fast properties mode）强制进入“字典模式”（dictionary mode）
- 所有后续属性读写不再通过内存偏移量计算，改走哈希表查找
- 即使再执行 obj.x = 5，V8 也不会自动切回快属性模式——该对象已被标记为“结构不稳定”
一次 delete 带来的连锁损耗
损耗远不止单次访问变慢，它会持续影响整个对象生命周期：
-
内联缓存全部失效：原本在函数中被 IC 高速缓存的
obj.name、obj.id等访问点，全部退化为慢速查找 - 触发去优化（deoptimization）：若该对象在已优化的热函数中被频繁访问，V8 会将函数回退到解释执行，重新编译成本更高版本
- 内存占用激增：字典模式需额外存储哈希表结构；实测百万级对象删一个字段，堆内存可暴涨 7–8 倍
为什么不能“恢复”隐藏类
隐藏类迁移链是单向且顺序敏感的。初始状态 C0 → 添加 x 得 C1 → 添加 y 得 C2。但 delete x 并不回到 C1 或 C0，而是彻底脱离该链，进入无结构描述的字典态。V8 没有“撤销删除”的机制，也没有重建原隐藏类的依据——因为对象当前结构已无法与任一已有隐藏类精确匹配。
真正可行的替代思路
不追求“物理删除”，而用语义等价、引擎友好的方式达成相同业务目标：
-
赋值 undefined 或 null：保持隐藏类不变，属性仍可被 IC 缓存（注意：在热函数中频繁赋
undefined仍可能触发去优化） -
构造新对象：用解构或
Object.fromEntries()过滤掉不需要的键，新对象从头拥有干净隐藏类 -
预定义完整结构：创建时就初始化所有可能字段（哪怕初值为
null），之后只更新、不增删 - 逻辑隔离：敏感字段（如密码）单独抽成子对象，删整个子对象不影响主对象隐藏类
结构稳定不是为了省几字节内存，而是让 V8 能持续信任你的对象——这种信任一旦丢失，就再也找不回来。
