html结构本身不触发内存回收，但深层嵌套（超6层）、冗余节点、内联事件绑定及未清理的documentfragment引用会阻碍gc，尤其在低端设备上；应重构dom深度、改用addeventlistener、显式清理引用。
HTML结构本身不触发内存回收，但深层嵌套、冗余节点和不当资源绑定会显著延缓或阻碍浏览器的内存回收（Memory Eviction），尤其在低端 Android 或旧款 iOS 设备上——这些设备的内存压力阈值更低，GC 触发更激进，而 DOM 节点残留正是最常被忽略的“回收障碍”。
DOM 节点深度超过 6 层会干扰 GC 可达性分析
浏览器 GC 不是单纯看“节点是否被 remove()”，而是基于引用图（reference graph）判断对象是否可达。当嵌套过深（如
<div><div><div><div><div><div><p></p></div></div></div></div></div></div>），父节点对子节点的引用链变长，V8 的标记-清除算法在遍历阶段更容易因栈深限制或超时提前终止，导致部分子树被误判为“不可达但未回收”。
- 用 Chrome DevTools → Elements 面板右键任意节点 →
Show DOM properties 查看 <code>depth值，超过 6 就该重构 - 移除冗余 wrapper 后，不仅节点数下降，
HTMLDivElement实例在堆快照中减少 30%+，GC 扫描耗时同步降低 - 语义化标签（如
<section></section>、<article></article>）与<div> 内存开销一致，但它们天然减少选择器复杂度，间接降低 CSSOM 树维护成本，释放更多 GC 时间片 <h3>内联事件绑定 + 深层嵌套 = 隐式强引用泄漏</h3> <p>写 <code><div onclick="handleClick()"><div><div><p>内容</p></div></div></div>看似无害，但 onclick 属性会隐式创建闭包，捕获整个父级作用域——包括所有祖先节点。一旦该节点被element.remove()，只要闭包还存活，整条嵌套链就无法被 GC 回收。- 避免内联事件：改用
element.addEventListener('click', handler)，并在销毁前显式调用removeEventListener - 若必须用内联，确保 handler 是全局函数（如
window.handleClick），且不闭包任何 DOM 引用 - 在堆快照中筛选
Closure构造器，展开后若看到大量HTMLDivElement被持有，基本可定位为此类泄漏
未清理的
DocumentFragment引用延迟内存释放很多人以为用了
DocumentFragment就一定安全，但若 fragment 被赋值给变量后长期持有（比如挂到window.cacheFrag），或 fragment 插入后又从 DOM 移除却没清空其子节点引用，它仍会拖住整棵子树。- fragment 仅在 append 到 DOM 后才真正参与渲染；插入前它只是内存中的轻量容器，不触发布局计算
- 插入后若需动态更新，优先复用 fragment（
frag.replaceChildren(...)），而非反复新建 - 不再需要时，设
frag = null，并确保无其他 JS 变量引用它 —— 否则 GC 无法判定其子节点已失效
真正卡住内存回收的，从来不是某个标签写错了，而是节点之间、JS 与 DOM 之间那些看不见的引用链。移动端设备没有冗余内存兜底，一次没清理的
addEventListener或一个忘置空的innerHTML变量，都可能让几百 KB 内存持续驻留数分钟——直到系统强制杀进程。 - 避免内联事件：改用
