dom节点移除后继续操作易致报错、内存泄漏或静默失效；最可靠判断其是否脱离文档的方式是检查node.isconnected属性，它零开销、兼容性好且准确。
DOM 节点一旦被移除（detached），它就不再属于文档树，此时继续在其上操作或监听，轻则报错，重则引发内存泄漏或静默失效。条件链路若未主动识别 detached 状态，容易在 removeEventListener、querySelector、MutationObserver.observe() 等调用中抛出异常，或让监听器“悬空”滞留。
先确认节点是否已脱离文档
最可靠、零开销的判断方式是检查 node.isConnected —— 它是原生只读属性，返回布尔值，不触发重排，且兼容性好（Chrome 51+、Firefox 53+、Safari 10.1+、Edge 79+）。
- ✅ 推荐写法：
if (!el.isConnected) return;或if (el.isConnected) { /* 安全执行 */ } - ❌ 避免用
document.contains(el)：需遍历整棵树，性能差；更糟的是，若 el 是 documentFragment 或 ShadowRoot 子节点，结果可能误判 - ❌ 不要用
el.parentNode === null：fragment 中的节点 parentNode 为 null，但并未 detached；而被 append 到其他文档（如 iframe）的节点也可能 parentNode 为 null，却仍活跃
监听器注销前加 detached 检查
在调用 removeEventListener 前，务必确认目标元素仍在文档中——不是为了防止报错（该方法本身容错），而是避免对已销毁节点做无意义调用，干扰调试与资源追踪。
- 对单个元素：直接
if (el.isConnected) el.removeEventListener('click', handler); - 对批量管理（如 WeakMap 映射）：遍历前先过滤
Array.from(map.keys()).filter(el => el.isConnected)，再逐个清理 - 特别注意 MutationObserver：observe() 方法在 detached 节点上调用会静默失败（不抛错但不生效），因此初始化前必须校验
targetEl.isConnected，否则 observer 将“假启动”
事件监听器绑定时就建立自动注销契约
与其依赖手动注销，不如从绑定阶段就约定生命周期。核心是利用 WeakMap + isConnected + 闭包清理逻辑，实现“节点一走，监听器自动失活”。
- 用 WeakMap 存储「元素 → 清理函数」映射，清理函数内部调用
removeEventListener并可执行其他收尾 - 绑定监听器时，同时注册一个微任务检测：
queueMicrotask(() => { if (!el.isConnected) cleanup(); });，确保即使同步移除也能及时响应 - 对异步挂载场景（如 Vue
onMounted/ ReactuseEffect），在 effect 清理函数中显式调用 cleanup，并再次检查el.isConnected防止竞态
修复回调中避免反向触发 detached 异常
MutationObserver 或自定义钩子的回调里，常需对变更节点执行修复（如移除广告 script、还原 style）。这些操作若作用于已 detached 的 target，可能引发 DOMException 或静默忽略。
- 修复前统一加守卫：
if (!mutation.target.isConnected || !container.contains(mutation.target)) return; - 不要直接
mutation.target.remove()：先判断mutation.target.parentElement?.contains(mutation.target)，再操作 - 涉及
innerHTML或textContent写入时，优先用textContent（无解析风险），并包裹 try/catch，捕获"HierarchyRequestError"等 detached 相关错误
