querySelector在动态节点下“查不到”并非bug，而是执行时序未对齐DOM更新、上下文错位、选择器过重所致；应确保DOM已挂载、限定作用域、精简选择器并缓存结果。
querySelector 在大批量动态节点下“刻舟求剑”，说的不是它笨，而是你用错了时机、选错了上下文、忽略了节点生命周期——它忠实地按你写的规则去查，可你查的那一刻，目标根本还没落进 DOM 里。
一、“查不到”不是 bug，是执行时序没对齐
动态插入的节点（比如 fetch 后 insertAdjacentHTML、Vue/React 渲染完成、小程序 createSelectorQuery 调用后），不会立刻出现在 DOM 树中。浏览器的渲染是分阶段的：JS 执行 → DOM 构建 → 样式计算 → 布局 → 绘制。querySelector 只在 JS 执行阶段运行，此时新节点可能只存在于内存字符串或虚拟 DOM 中，尚未挂载。
- 常见错误写法：
el.insertAdjacentHTML('beforeend', html); const target = el.querySelector('.new-item');—— 此时 target 几乎必为 null - 正确做法：确保 DOM 已更新。可用
requestAnimationFrame或MutationObserver监听插入完成 - 更稳妥的替代：对已知结构，改用事件委托（如监听父容器的
click并用e.target.matches('.new-item')判断）
二、批量操作时，“查一次再遍历”不如“查即用”
面对数百个动态生成的同类节点，有人习惯先 querySelectorAll('.item') 拿全集，再 forEach 处理——这看似合理，实则埋雷：若后续又有新节点插入，这个 NodeList 是静态的，不会自动更新；而反复调用 querySelectorAll 又浪费性能。
- 推荐模式：把逻辑封装成函数，需要时就地查、就地用。例如：
function handleNewItem(el) { const logo = el.querySelector('.logo'); if (logo) logo.src = getLogoUrl(el); } - 配合事件委托，避免主动查询：给容器绑定
click，用e.target.closest('.item')定位触发源，再查其内部子元素 - 若必须批量处理，优先用
Array.from(document.querySelectorAll(...))转真数组，再链式操作，不依赖 NodeList 原生方法兼容性
三、上下文错位：你以为在“大海”里找，其实只在“水杯”里扫
querySelector 默认从 document 开始搜，但大量动态节点实际挂在某个局部容器内（如 #list、.modal-content）。若直接 document.querySelector('.dynamic-btn')，可能命中旧模板、隐藏区域甚至 Shadow DOM 外的残留节点。
- 务必限定作用域：拿到父容器后，用
container.querySelector(...)或container.querySelectorAll(...) - 注意 Shadow DOM 隔离：若节点在自定义元素 shadowRoot 内，必须显式访问
el.shadowRoot.querySelector(...) - 避免全局污染：动态插入前，先清理旧节点（如
container.innerHTML = ''），否则 querySelector 可能误匹配已被移除但未 GC 的旧引用
四、性能陷阱：复杂选择器 + 高频调用 = 主线程卡顿
在滚动、输入、动画等高频场景下，反复执行 document.querySelector('div[data-id="123"] .meta > span:last-child') 这类深度嵌套选择器，会触发浏览器反复遍历 DOM 树，尤其当页面节点数过万时，极易引发掉帧。
- 精简选择器层级：优先用 class 或 data-* 属性直取，避免多层后代（
:nth-child） - 缓存结果：对稳定不变的容器，存为变量（
const list = document.getElementById('list');），后续操作复用 - 分片处理：需遍历上千节点时，用
setTimeout或requestIdleCallback拆成小块，避免阻塞用户交互
