内存飙升主因是DOM节点及JS引用链累积，而非模板本身；未及时清理的Detached DOM、未升级的HTMLUnknownElement、connectedCallback重复执行、事件监听器滥用及动态插入遗漏upgrade均加剧内存泄漏。
大规模组件加载时为什么内存会飙升
不是模板本身吃内存，而是浏览器解析 HTML 后构建的 DOM 节点 + 关联的 JS 引用链在持续累积。一个 <my-card></my-card> 组件哪怕只渲染 1000 次，若每次都在 connectedCallback 中重复创建 Shadow DOM、绑定事件、发起 fetch，就等效于每秒新增上千个强引用对象；更常见的是用 innerHTML 批量插入后又没清理旧节点，导致 Detached DOM tree 堆积——$$('*').length 每次操作后稳定增长就是最直接信号。
customElements.define 必须在 HTML 解析前完成
浏览器遇到未注册的自定义标签（如 <data-table></data-table>）会先建 HTMLUnknownElement，之后再调用 customElements.define() 不会自动升级已有节点。这些节点永远不触发 connectedCallback，但依然占内存、响应样式、参与布局计算。
- 错误做法：
window.addEventListener('DOMContentLoaded', () => { customElements.define('x-list', XList); });—— 此时 HTML 已解析完毕，页面里所有<x-list></x-list>都是“僵尸元素” - 正确做法：内联脚本或
<script type="module" defer></script>，确保注册早于首个自定义标签出现 - 兜底方案：对已插入的节点手动调用
customElements.upgrade(node)，但仅限必要节点，避免全量遍历
connectedCallback 里必须防重复初始化
这个回调不是构造函数，它会在组件被反复挂载/显示时多次触发（比如 Vue 列表重渲染、display: none 切回、appendChild 多次调用）。不加防护会导致 Shadow DOM 多次 attach、事件监听器叠加、定时器失控、fetch 请求发爆。
- 用私有字段标记：
this._isInitialized = true，开头加if (this._isInitialized) return - Shadow DOM 初始化必须包裹在
queueMicrotask(() => { this.attachShadow(...) })，否则this.shadowRoot可能为 null - 异步操作（如 fetch）需保存
AbortController实例，并在disconnectedCallback中调用abort()
事件代理 + WeakMap 是大规模预览组件的标配
给每个组件实例单独绑 addEventListener 是内存灾难源头：10 万个卡片 = 10 万个函数闭包 + 对应 DOM 引用，GC 无法回收任何一环。事件代理把监听器压到 1 个，再配合 WeakMap 存关联数据，才能真正解耦。
立即学习“前端免费学习笔记（深入）”；
- 父容器必须稳定存在且生命周期可控，例如
document.getElementById('component-grid')，绝不用document.querySelector('.grid')这类易失效选择器 - 委托回调中禁止缓存
e.target到全局变量或长生命周期对象；必须用e.target.closest('[data-component-id]')动态提取 - 需要存储组件状态时，用
const stateMap = new WeakMap()关联 DOM 节点与数据，节点卸载后自动清理
insertAdjacentHTML 渲染新卡片后忘了 upgrade，或者在事件回调里随手写了 const el = e.target; cache.push(el)。这些行为不会立刻报错，但会让 $$('*').length 在用户滚动几次后悄悄翻倍，直到某次 GC 触发卡顿才暴露。 
