delete删除对象属性会破坏V8隐藏类，导致内联缓存失效、访问降速2–5倍，甚至退化为字典模式；应改用undefined占位、构造新对象或预定义结构来维持属性稳定性。
直接用 delete 删除对象属性，表面看只是移除一个字段，实则会触发 V8 引擎底层一系列代价不菲的调整——核心在于它破坏了对象的隐藏类（hidden class）结构，使后续所有属性访问都失去内联缓存（IC）优化，性能明显下滑。
隐藏类一旦断裂，访问变慢是必然结果
V8 为结构一致的对象分配相同的隐藏类，借此实现属性地址的快速定位。只要对象新增、删除或重命名属性，V8 就必须为其创建新隐藏类，甚至退化为字典模式（dictionary mode）。此时每次读写属性都要动态查表，无法复用已缓存的偏移量。
- 一个频繁被 delete 的对象，在循环中反复访问剩余属性，实际可能比初始慢 2–5 倍
- 若该对象被多个函数共用，所有相关内联缓存全部失效，影响范围远超单次 delete 操作
- 这种退化在生产环境不易察觉，但压测时 CPU 时间常集中在 PropertyAccessStub 等底层调用上
delete 不是“轻量操作”，而是结构重排
它不是简单抹掉一个键值对，而是迫使引擎重建对象内部描述：更新属性映射表、重算哈希分布、检查原型链可枚举性……尤其当对象已有数十个属性或经历过多次增删后，开销进一步放大。
- 在 Chrome DevTools 的 Performance 面板中，delete 操作常表现为高亮的 “Runtime.callFunction” 或 “JSObject::DeleteProperty” 事件
- 配合 Object.defineProperty 设置为 configurable: false 的属性，delete 会直接返回 false，但引擎仍需执行完整校验流程
- 数组上使用 delete（如
delete arr[2]）不仅不改变 length，还会让数组从快数组（fast elements）退化为稀疏数组（dictionary elements），后续遍历效率骤降
替代方案更可控、更稳定
真正需要“逻辑删除”时，优先选择不影响对象结构的方式：
-
设为
undefined：语义清晰，结构不变，V8 仍能复用原有隐藏类 -
构造新对象：用解构或
Object.fromEntries()过滤，适用于一次性的精简场景 - 预定义属性集：初始化时就声明所有可能用到的字段（哪怕暂为 null），避免运行时结构变更
-
用 Map 替代普通对象：Map 的
delete()不影响其内部结构稳定性，适合高频增删键值对的场景
delete 操作符本身没有错，但它暴露的是设计假设的脆弱性——把对象当作可随意整形的容器，却忽略了 JS 引擎为“稳定结构”所做的大量优化努力。控制结构变化，就是守住性能底线。
