dom查询是静态的，需配合mutationobserver监听变化并局部重查：监听childlist/subtree捕获增删、attributes监听属性变更，并缓存已处理节点避免重复，精确指定容器防性能损耗。
DOM 查询本身是静态的，比如 document.querySelector 或 getElementById 只返回调用时刻存在的节点，不会自动响应后续结构变化。要让查询逻辑“活起来”，就得配合 MutationObserver 在 DOM 变更后重新执行或更新查询结果。
监听子节点增删并触发重查询
适用于容器内动态插入/移除元素的场景，例如评论列表、商品卡片、通知气泡等。
- 配置
childList: true和subtree: true，确保捕获直接子节点及深层嵌套的变化 - 在回调中对
mutation.addedNodes做过滤（如只处理nodeType === 1的元素节点），再对新节点运行查询逻辑 - 避免每次变动都全量查一遍；可只查新增节点内部，或缓存目标节点引用并在移除时清理
监听属性变更后按需更新查询目标
当目标元素靠 class、data- 属性或状态标识定位时，属性变化可能意味着它“变成”了新目标。
- 启用
attributes: true并设置attributeFilter（如['class', 'data-status']）缩小监听范围 - 配合
attributeOldValue: true，能判断是否从非目标态变为目标态（例如data-status="pending"→"done"） - 在回调里用
mutation.target直接检查该元素是否符合新查询条件，无需重新遍历整个 DOM
结合查询与事件绑定的典型流程
常见于 SPA 或第三方脚本注入内容后需要补上交互逻辑（如按钮点击、表单验证）。
- 先定义一个封装好的查询+初始化函数，例如
initInteractiveElements(container) - 首次调用它处理已有节点
- 用 MutationObserver 监听该容器，一旦有
addedNodes，就对每个新元素调用相同初始化函数 - 记得在页面卸载或组件销毁前调用
observer.disconnect()，防止内存泄漏
避免重复查询和性能陷阱
MutationObserver 回调是异步批量触发的，但不当使用仍会导致冗余操作。
- 不要在回调里反复调用
document.querySelectorAll('.target')全局扫描——优先基于mutation.target或addedNodes局部查找 - 如果只是想“确保某类元素存在即被处理”，可用
Set缓存已处理过的节点node.isInitialized = true，跳过重复项 - 不监听
document.body这类大范围节点；精确指定容器，减少无关变动干扰
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
