div ul li a 比 .nav-link 慢，因CSS选择器从右向左匹配，前者需遍历全部a元素再逐层向上验证父级，回溯开销大；后者直接哈希定位class，高效精准。
为什么 div ul li a 比 .nav-link 慢？
CSS 选择器是从右向左匹配的，浏览器先找所有 a 元素，再向上逐层验证是否在 li 内、是否在 ul 内、是否在 div 内。层级越深、范围越广，回溯越多，尤其在 DOM 节点数多时，渲染引擎开销明显上升。
典型表现不是“页面卡”，而是样式计算（Style Calculation）阶段耗时突增，在 Chrome DevTools 的 Performance 面板中能看到 Recalculate Style 时间占比异常高。
- 避免用标签名做左侧锚点，比如
section article p——p太泛，命中过多候选节点 - 慎用通配符和属性选择器：
[class*="btn"]、*[role="button"]无法被高效索引 -
:not()内部若含复杂选择器（如:not(.foo div span)），会显著拖慢匹配速度
如何用 DevTools 定位低效选择器？
Chrome 115+ 已支持在 Rendering 设置中开启 Highlight paint regions 和 Enable CSS selector profiling（需在 chrome://flags/#devtools-css-selector-profiling 启用实验功能）。启用后，在 Styles 面板悬停选择器，会显示「匹配耗时预估」和「匹配节点数」。
- 重点关注右侧是通用标签（
div、span、*）或伪类（:hover、:nth-child）的选择器 - 在
Performance录制中筛选Layout或Recalculate Style事件，点击展开 → 查看Related Events→ 找到触发该计算的 CSS 规则行号 - 用
document.querySelectorAll("your-selector")在控制台手动测节点数量：超过 500 个就值得优化
哪些“看起来安全”的写法其实很危险？
很多团队误以为加了 class 就没问题，但组合方式仍可能触发深层遍历。关键不在有没有 class，而在最右部分是否足够唯一、是否可被哈希索引。
立即学习“前端免费学习笔记（深入）”；
-
.container .sidebar ul li a：问题在最右的a，浏览器仍要遍历全部a标签 -
body .theme-dark button[disabled]：属性选择器 + 深层结构，无法利用 class 索引加速 -
.list > *:nth-child(2n)：伪类强制全量计算子节点顺序，*进一步放大代价 - 正确做法是把关键标识尽量往右放：
a.nav-link、button.btn--primary、[data-testid="submit-btn"]
全局样式（如 html、body、*）为什么必须限制？
以 body * { box-sizing: border-box; } 为例：它会在每次插入新节点、甚至动态添加 class 时，触发对整个 body 子树的重匹配。现代框架（React/Vue）高频更新 DOM 时，这类规则会成为隐性性能热点。
- 改用更精确的作用域：
body .app *, .app *::before, .app *::after - 用 CSS 自定义属性替代重复声明：
:root { --box-sizing: border-box; }，再在组件内用box-sizing: var(--box-sizing); - 避免在
@keyframes或@media中嵌套全局选择器，媒体查询激活时会重新走一遍全量匹配
真正影响性能的往往不是单条规则，而是成百上千条规则里那几条“看似无害”的深层匹配。优化重点不在删代码，而在让浏览器少做无谓的向上回溯——把唯一性交给最右边，把范围收束在最小必要 DOM 子树内。
