关键选择器决定初始筛选范围，浏览器从右向左匹配，用关键选择器（如#header、.btn）快速定位候选节点；若为div、*、[data-testid]等则触发全量扫描，:has()更导致逐节点遍历。
关键选择器决定初始筛选范围
浏览器不是“拿着 CSS 去找 DOM”，而是对每个 display != none 的节点，逐条判断“这条规则要不要应用到它身上”。从右向左匹配，本质是先用最右边那个部分（即关键选择器）快速圈定候选节点——比如 #header 或 .btn，浏览器能直接走哈希索引，O(1) 定位；而如果关键选择器是 div、* 或 [data-testid="save"]，就得对全部节点挨个比对。
-
input[type="text"]看似具体，但属性匹配无索引，实际比加个.text-input类慢一个数量级 -
form * .error中的*在关键位置，等于让浏览器对每个节点都跑一次检查 -
[aria-hidden]单独用不慢，但作为关键选择器（如[aria-hidden] + button）就触发全量扫描
回溯验证比全量遍历更早失败
后代选择器（如 nav ul li a）的性能瓶颈不在“写了四层”，而在匹配时要对每个 a 向上验证三层父级结构：是不是 li 的子元素 → 是不是 ul 的后代 → 是不是在 nav 内。这个过程一旦某层不满足就立刻终止，避免了从 nav 开始往下钻、再发现底下根本没 ul 的白忙活。
- 写
section article header h1不比.page-title多花 4 倍时间，但实测 5000 节点页面中，4 层后代选择器比 BEM 单类名慢 3.2 倍 -
.main-nav a比.main-nav > ul > li > a快得多：前者先定位.main-nav节点，再在其内部找a；后者每个a都得向上跳 3 级验证 - DOM 节点越多、嵌套越深，回溯路径越长，耗时呈非线性增长
:has() 和测试属性会破坏右向逻辑
:has() 是目前唯一强制左向查找的伪类，Chromium 虽已支持，但无法缓存、不能索引。一旦出现在关键路径（如 article:has(.highlight)），整个匹配逻辑退化为逐节点遍历——相当于把“先筛再验”变成“每个节点全查一遍”。
-
@media (prefers-reduced-motion)包裹的规则仍全程参与匹配，建议外链隔离非核心样式 -
[data-testid="xxx"]出现在关键位置（如[data-testid="save-btn"]），等同于全量扫描，生产环境必须替换为.test-save-btn -
*[hidden]或form *这类通配写法，必须删除——它们会让浏览器对每个 DOM 节点都执行一次检查
高频更新区域尤其要避开空格分隔选择器
在列表项、弹窗内容、实时评论流这类频繁增删节点的区域，使用 .list .item .content 这类空格分隔选择器，每次 DOM 变更都会触发整条规则重匹配。浏览器要重新抓所有 .content 节点，再逐个向上验证是否在 .item 内、是否属于 .list。
立即学习“前端免费学习笔记（深入）”；
- 推荐改用单类名（如
.list-item-content）或数据属性 + JS 控制（[data-list-item="content"]） - Less/Sass 嵌套超 3 层后，样式计算耗时平均上升 40% 以上，低端安卓 WebView 中更明显
- 哪怕只是
article p strong这种看似简单的选择器，在 200 段落长文中也可能因上千个strong元素引发严重回溯开销
真正拖慢渲染的，往往不是选择器“写得复杂”，而是关键选择器无法快速锚定目标节点，或者回溯路径被无意拉长。很多性能问题藏在看似无害的 [data-testid] 或 :has() 里，上线前很难察觉。
