事件代理能降内存，是因为只在父容器绑定1个监听器，避免为10万个节点各自创建函数实例和闭包，防止dom节点被引用“钉”在内存中；配合结构精简与动态清理，实测5万节点内存可从120mb降至25mb。
为什么大规模预览节点用事件代理能降内存
10 万个预览卡片（比如商品缩略图、文档封面）如果每个都 addEventListener('click', handler)，光函数引用 + 闭包就吃掉几十 MB 堆内存；更糟的是，这些监听器会把对应 DOM 节点、父级作用域变量全部“钉”在内存里，哪怕卡片被移出视口甚至从 DOM 删除，只要监听器没解绑，它们就是 Detached DOM tree，GC 不收。
事件代理只在父容器上绑 1 个监听器，靠 e.target.closest() 动态识别点击目标——DOM 节点本身不持有 JS 引用，卸载时自然释放。实测 5 万节点下内存占用可从 120 MB 降到 25 MB 左右。
父容器怎么选才不会出问题
必须选一个**生命周期稳定、不随内容频繁重建**的容器。常见错误是绑定到 document 或 body：全局监听器难清理，容易漏掉 removeEventListener，且回调里若误存 e.target 到全局变量，整页都卡内存。
- ✅ 推荐：用明确 ID 的 wrapper，如
<div id="preview-grid"></div>，初始化时只绑一次 - ⚠️ 避免：
document.querySelector('.preview-list')这种靠 class 查找的写法——若组件重渲染导致该元素被销毁重建，新旧容器监听器可能共存 - ⚠️ 必须确保脚本执行时该容器已挂载 DOM，否则
addEventListener静默失败，后续所有点击都不响应
closest() 比 matches() 和 className 更安全
预览节点结构常嵌套较深（比如 <div class="card"><div>
<img><div class="card-footer"><button class="preview-btn"></button></div>
</div></div>），直接判断 e.target.classList.contains('preview-btn') 会失败——因为用户可能点到按钮内的图标或文字节点。
e.target.closest('.preview-btn') 向上遍历祖先，天然兼容任意嵌套层级，且返回值是 null 而非抛错，适合条件分支：
const container = document.getElementById('preview-grid');
container.addEventListener('click', e => {
const btn = e.target.closest('[data-action="preview"]');
if (!btn) return;
// 只有这时才读取数据，避免闭包捕获整个卡片节点
const id = btn.dataset.id;
openPreview(id);
});
动态插入新预览节点时要不要重新绑定
完全不用。事件代理的核心优势就是“一次绑定，永久生效”——只要新节点插入到同一个父容器内，冒泡路径不变，监听器就能捕获。
但要注意两个坑：
- 插入后别立刻调用
container.querySelectorAll('[data-action="preview"]')去批量加监听，这等于退化回传统模式 - 若预览节点含
<video></video>或<canvas></canvas>，它们自身可能偷偷占内存，需单独清理：video.src = ''→URL.revokeObjectURL(video.src)→video.load()，不能只靠事件代理
最易被忽略的点：事件代理省了监听器内存，但没省 DOM 节点本身。如果预览卡片 HTML 结构冗余（比如 5 层嵌套 <div> 包一个 <code><p></p>），每个节点仍占 1–2 KB。先砍结构，再上代理，效果翻倍。
