removeChild 本身不会导致内存泄漏，真正原因是移除后仍持有引用或未解绑事件监听器；它仅断开 DOM 树连接，若变量、缓存或事件处理器仍引用该节点，GC 就不会回收。
直接说结论：removeChild 本身不会导致内存泄漏，但“移除后仍持有引用”或“漏掉事件监听器”才会真正引发泄漏。
为什么 removeChild 后 DOM 还占着内存？
浏览器的垃圾回收（GC）只释放“不可达对象”。removeChild 只是把节点从 DOM 树断开，如果代码里还存着这个节点的引用（比如赋值给了某个变量、缓存进了数组、绑定了未解绑的事件），它就仍是“可达”的，GC 不会动它。
- 常见错误现象：
const el = document.getElementById('box'); parent.removeChild(el); console.log(el); // 依然能访问，且 el 仍持有所有事件和子元素引用 - 典型场景：动态表格重绘、弹窗反复打开关闭、列表项缓存复用
- 关键点：
removeChild不等于“销毁”，它只是“断连”
移除前必须手动清理的三件事
在调用 removeChild 之前，务必确认以下操作已完成：
- 调用
el.removeEventListener('click', handler)解绑所有显式绑定的事件（包括委托到它的事件监听器，如果该节点曾作为事件代理目标） - 将节点上挂载的自定义属性清空，尤其是对象、数组、Promise 或回调函数：
el.myData = null; el.cache = null; - 如果节点内含
canvas、video、audio等资源，手动调用canvas.getContext('2d').clearRect()或video.src = ''
removeChild vs innerHTML = '' 的陷阱
两者行为完全不同，选错会放大泄漏风险：
-
parent.removeChild(el)：只移除单个节点，保留其他子节点，适合精准控制；但你必须自己负责该节点的后续清理 -
parent.innerHTML = ''：暴力清空全部子节点，浏览器内部会批量断开引用，**但不保证事件监听器被自动解绑**（尤其通过addEventListener绑定的） - 性能影响：大量子节点时，
innerHTML = ''可能触发重排重绘；而逐个removeChild更可控，但循环中未及时解除引用反而更危险 - 兼容性无差异，现代浏览器均支持，但 SSR 或 Shadow DOM 场景下需注意
innerHTML可能被拦截或忽略
更安全的替代写法：封装一个 safeRemove
把清理逻辑收束成一个可复用函数，避免每次手动重复：
function safeRemove(el) {
if (!el || !el.parentNode) return;
// 解绑所有已知事件（实际项目中建议维护 handler 映射表）
el.onclick = null;
el.oninput = null;
// 清理自定义属性
for (const key in el) {
if (key.startsWith('on') && typeof el[key] === 'function') {
el[key] = null;
}
}
// 移除
el.parentNode.removeChild(el);
// 最后置 null（对局部变量有效，对闭包引用无效）
el = null;
}
注意：这个函数不能解决闭包强引用问题（比如某个闭包里长期持有 el），那得靠业务层主动切断引用链。真正的难点永远不在 removeChild 这一行，而在它前后那几行没人 review 的清理逻辑。
