应限定 querySelector 查询作用域、精简选择器结构、预提取批量处理、用 matches 替代嵌套查找；避免从 document 全局查、禁用高代价组合器与属性选择器，优先使用标签+类组合及已知父容器为上下文。
在大规模复杂 DOM 树中，querySelector 本身不会“全表扫描”，但不当使用会触发浏览器遍历远超必要的节点范围——本质是**路径选择不当 + 上下文过宽**导致的隐式全量遍历。关键不是避免 querySelector，而是控制它查什么、在哪查、怎么写。
限定查询作用域，别总从 document 开始
全局查找是性能杀手。document.querySelector('.item') 会从根开始逐层匹配；而 container.querySelector('.item') 只查 container 的后代子树，搜索节点数可能减少 90% 以上。
- 优先用已知父容器（如模块 wrapper、卡片元素、弹窗 DOM 节点）作为查询起点
- 组件化开发中，把 this.$el 或 shadowRoot 当作默认上下文，而非无脑 document
- 动态插入的 DOM，立即在其父节点上调用 querySelector，不等它挂到 document 再查
精简选择器结构，避开高代价写法
某些选择器会让浏览器放弃快速索引路径，退化为深度遍历：
- 避免
.modal.is-open .close-btn这类依赖状态类的选择器——状态可能随时变化，且无法预判匹配位置；改用.modal-close-btn这种唯一、语义明确的类名 - 禁用
:not()、*、+、~等通用组合器，它们常触发额外全量扫描或回溯匹配 - 少用属性选择器如
[data-id]（无索引支持），优先用button.submit这种“标签 + 类”组合，浏览器能快速按标签过滤再筛类
预提取 + 批量处理，减少重复调用
频繁调用 querySelector 是隐形瓶颈，尤其在循环中。一次查出、多次复用更高效：
- 需要多个同类元素时，用
container.querySelectorAll('input[type="text"]')一次性获取，再用Array.from()或扩展运算符转数组处理 - 避免在 forEach 中反复写
el.querySelector('.label')，提前用Array.from(container.children, el => ({el, label: el.querySelector('.label')}))预提取 - 对数百个节点操作时，先批量读取 offsetTop、dataset 等属性，再统一写入 class 或 style，减少重排重绘
用 matches 判断替代嵌套查找
当只需判断某个元素是否符合某规则时，el.matches('.valid[data-type="email"]') 比 container.querySelector('.valid[data-type="email"]') === el 快得多——前者是单元素匹配，后者仍需遍历找匹配项。
- 适合表单校验、事件委托目标过滤、条件渲染前判断等场景
- 配合事件委托使用：在父容器监听 click，用
e.target.matches('button.delete')判断是否要响应，无需事先查所有按钮
