JavaScript 中 delete 操作不直接释放内存，但会破坏 V8 的隐藏类机制，导致内联缓存失效、对象退化为字典模式，显著降低后续属性访问性能。
JavaScript 对象属性删除操作本身不直接释放内存，但会间接引发性能问题，核心影响在于破坏 V8 引擎的隐藏类（Hidden Class）机制，进而导致内联缓存失效、对象退化为字典模式，最终拖慢后续所有属性访问速度。
隐藏类被破坏，访问变慢
V8 为结构一致的对象分配相同隐藏类，记录各属性在内存中的固定偏移量，使属性读写能跳过查找、直接定位。一旦执行 delete obj.prop，对象结构就变了，V8 必须创建新隐藏类或降级为字典模式——此时每次取值都要哈希查找，开销显著上升。
- 即使只删一次，该对象后续整个生命周期都失去优化收益
- 多个同类对象因 delete 操作产生不同隐藏类，无法共享优化路径
- 若在已 JIT 编译的函数中频繁 delete，还会触发去优化（deoptimization），回退到解释执行
容易误入字典模式
以下行为会让对象进入低效的字典模式：
- 循环中反复增删同一属性（如 for (let k in obj) delete obj[k]）
- 先删属性再以不同类型重设（如删 obj.x = 1，再设 obj.x = 'a'）
- 对长期存活、高频访问的对象使用 delete
字典模式下，属性不再按顺序存储，也无法享受快速字段访问（fast property access），内存布局更松散，CPU 缓存友好性下降。
立即学习“Java免费学习笔记（深入）”；
内存回收其实不受直接影响
delete 不等于释放内存。它只是断开对象自身对该属性的引用；真正触发垃圾回收的是：该属性值不再被任何变量或闭包持有。
- 如果被删属性的值是大型数组或 DOM 节点，且其他地方仍有引用，delete 并不会让它被回收
- 反之，若值已无任何引用，即使不 delete，GC 同样会回收——关键在引用链，不在 delete 操作本身
- 用 obj.prop = undefined 或 null，同样能切断引用，且不破坏隐藏类
更稳妥的替代方式
保持结构稳定比“看起来删得干净”更重要：
- 赋值为 undefined：语义清晰，隐藏类不变，GC 条件满足时照常回收值
- 解构生成新对象：如 const { unwanted, ...rest } = obj，原对象不动，新对象结构纯净
- 构造时预设完整结构：在 class 或工厂函数中初始化所有可能字段（哪怕为 null），之后只更新不删除
现代 JS 引擎对未使用的属性空间管理很高效，结构稳定带来的运行时收益远超节省几个字节的假想优势。
