大屏不能依赖浏览器默认DOM生命周期回收节点，必须手动池化管理；因connectedCallback不重复触发、disconnectedCallback在页面刷新、后台冻结、滚动复用等场景下根本不执行，导致定时器和事件监听器长期滞留，引发内存抖动与回流风暴。
大屏不能依赖浏览器默认 DOM 生命周期回收节点，必须手动池化管理——connectedCallback不重复触发、disconnectedCallback不保证执行，指望自动清理等于放任内存抖动和回流风暴。
为什么 disconnectedCallback 不能当清理入口
它只在元素被明确从主 DOM 树移除时才可能调用，但以下场景根本不会触发：
- 页面刷新或崩溃时，进程直接终止，回调永不执行
- 标签页切到后台后被浏览器冻结，
disconnectedCallback被跳过 - 滚动中反复
removeChild()+appendChild()已挂载过的节点，浏览器认为“还是同一个”，不触发回调
更危险的是：你在里面清除定时器、解绑事件，结果这些资源永远滞留。实测某告警卡片组件因依赖此回调，单页运行 8 小时后泄漏 120+ 个 setInterval 实例。
用 Map + dataset.id 实现安全节点池化
核心不是“回收”，而是“擦写复用”：节点不销毁，只隐藏 + 更新内容。关键约束有三条：
立即学习“前端免费学习笔记（深入）”；
- 每个节点初始化时必须写死
dataset.id，且全局唯一（如card-cpu-001），不能靠索引生成 - 结构必须固定：子元素 class 名、层级、插槽位置全不可变；禁止在复用时
innerHTML = ''或appendChild() - 缓存容器必须用
Map，不用数组——避免滚动导致的索引漂移，防止数据错位渲染
示例逻辑：
const nodePool = new Map();
function recycleNode(node) {
if (node.dataset.id && !nodePool.has(node.dataset.id)) {
node.style.display = 'none'; // 不 detach，保事件绑定
nodePool.set(node.dataset.id, node);
}
}
function acquireNode(id, data) {
let node = nodePool.get(id);
if (node) {
node.style.display = '';
node.querySelector('.value').textContent = data.value;
node.dataset.updated = Date.now();
nodePool.delete(id);
return node;
}
// fallback：创建新节点（仅首次）
}
滚动监听里最容易踩的三类 DOM 操作坑
大屏滚动更新常卡在“看似合理”的操作上：
- 在
scroll回调里直接调用el.remove()→ 每帧触发回流 + 事件丢失 + 内存分配压力 - 用
getBoundingClientRect()或offsetTop判断是否出视口 → 强制同步 layout，一帧内多次调用直接拖慢 3–5 倍 - 对列表项批量
innerHTML = template(data)→ 销毁所有子节点，包括已绑定的addEventListener和 Canvas 上下文
正确做法是：用 IntersectionObserver 判断可见性，配合节流 + requestAnimationFrame 批量更新；所有动态内容只改 textContent、dataset、src 这类低开销字段。
真正难的不是写池化逻辑，而是让整个团队接受“节点是白板，不是一次用品”——只要结构稍有变动（比如加个图标 wrapper），复用就失效，而这种改动往往藏在 UI 组件库的 minor 版本里，上线前很难被发现。
