querySelector 支持多条件级联筛选，如 .sidebar .menu-item a[data-role="primary"]:not([disabled])，一次性匹配全部条件，无需嵌套循环；注意 :has() 兼容性，SPA 中避免缓存 NodeList，框架内优先用响应式逻辑而非直接查 DOM。
用 querySelector 实现多条件级联筛选，别写嵌套循环
原生 DOM 查询完全支持多条件组合，querySelector 的选择器语法本身就能表达“父级有某类、子元素带某属性、且含特定文本”的逻辑，不需要先 getElementsByClassName 再遍历过滤。
常见错误是把级联当步骤：先找 .category，再对每个结果调 .querySelector('a[data-active="true"]')——这在数据量大时明显变慢，且容易漏掉深层嵌套或动态插入的节点。
- 正确写法示例：
document.querySelector('.sidebar .menu-item a[data-role="primary"]:not([disabled])')，一次性定位到满足全部条件的元素 -
:not()、:has()（Chrome 105+）、[attr^="val"]等伪类和属性选择器可直接参与级联，无需 JS 逻辑介入 - 注意浏览器兼容性：
:has()在 Safari 15.4+ 和 Firefox 121+ 才稳定支持，生产环境慎用，可用closest()+matches()回退
querySelectorAll 返回的是静态 NodeList，但很多人误以为它会响应 DOM 变化
这是高频误解。即使你监听了 DOMSubtreeModified（已废弃）或用 MutationObserver，querySelectorAll 的结果也不会自动更新——它只在调用那一刻快照 DOM 结构。
- 如果页面后续动态插入匹配的新节点，必须重新调用
querySelectorAll获取最新列表 - 不要缓存结果后长期复用，尤其在 SPA 中：路由切换、组件重渲染后，旧 NodeList 中的节点可能已脱离文档树，调用
.textContent或.click()会静默失败 - 需要实时响应时，优先用事件委托：
document.addEventListener('click', e => { if (e.target.matches('.btn[data-type="export"]')) { ... } })
级联选择器里 class 和 data 属性混用时，顺序影响匹配结果吗？
不影响匹配逻辑，但影响可读性和维护性。CSS 选择器权重规则不适用于 querySelector 匹配（它只管是否匹配，不管“谁更优先”），但书写顺序暴露意图。
- 推荐把结构性条件放前（如
.container .list li），状态性条件放后（如[data-status="pending"]），便于快速识别层级和过滤意图 - 避免写成
[data-id][data-type="user"].active这种无上下文的组合——没人能一眼看出这是查用户卡片还是表单项 - 特别注意空格：
.a.b表示“同时含 a 和 b 两个 class”，而.a .b表示“a 后代里的 b”，少一个空格语义全变
Vue/React 项目里还该用 querySelector 做级联筛选吗？
大多数情况不该。框架的响应式机制和虚拟 DOM 已经接管了状态与视图同步，绕过框架直接操作 DOM 容易引发状态不一致。
- Vue 中应优先用
ref+v-if/v-show控制显隐，筛选逻辑写在computed；真要查 DOM（比如聚焦输入框），用nextTick确保渲染完成后再querySelector - React 中同理，用
useRef+useEffect，避免在render函数里调用querySelector（此时 DOM 还没生成） - 唯一合理场景：集成第三方非框架组件（如地图 SDK、富文本编辑器），它们内部管理 DOM，只能靠选择器桥接
真实项目里最常被忽略的，是级联选择器和框架生命周期的错位——不是语法不会写，而是忘了“什么时候才能安全地查”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
