div ul li a 比 .nav-link 慢，因浏览器从右往左匹配，前者需逐层回溯父级，计算量指数增长，后者通过哈希查找接近常数时间；多层嵌套选择器叠加会显著增加样式计算耗时。
为什么 div ul li a 比 .nav-link 慢
浏览器解析 CSS 选择器是从右往左匹配的，div ul li a 这种长链式结构会让引擎在 DOM 树中反复回溯：先找所有 a，再逐个检查父级是否为 li，再往上查 ul……层级越深，候选节点越多，计算量指数级增长。.nav-link 则直接哈希查找，几乎常数时间。
常见错误现象：DOMContentLoaded 时间正常，但页面滚动或动画卡顿，DevTools 的 “Rendering” 面板显示频繁重排重绘；用 Performance 录制时看到大量 Recalculate Style 占用主线程。
- 使用场景：组件库通用样式、老项目遗留的嵌套列表导航、CMS 输出的无 class HTML
- 性能影响：单条规则影响小，但几十条类似选择器叠加后，样式计算耗时可能从 0.1ms 跃升至 5ms+（尤其在低端 Android 设备）
- 兼容性无问题，但代价是运行时开销——不是“写不出来”，而是“跑得累”
如何快速定位低效选择器
Chrome DevTools 的 Coverage 面板不统计选择器效率，得靠 Rendering → Paint Profiling 或强制触发样式计算来抓热点。更直接的办法是启用“CSS Selector Profiler”实验功能（chrome://flags/#enable-css-selector-profiler），重启后在 Elements 面板右键元素 → “Force element state” → 观察右侧 Styles 面板里每条规则的匹配耗时标记（需开启“Show rules that match current element”）。
- 优先筛出带 >、+、~ 和多层嵌套的规则，比如
section > article > header > h2 - 警惕通配符和属性选择器混用，如
[data-role] .item:hover—— 属性匹配本身慢，再加伪类更拖累 - 构建时可用
stylelint插件stylelint-selector-bem-pattern或自定义规则拦截超过 3 层的后代选择器
:is() 和 :where() 能简化结构但不解决根本问题
像把 header nav ul li a 改成 :is(header, nav, ul, li) a 看似缩短了写法，实际匹配逻辑没变：浏览器仍要对每个 a 检查其任意祖先是否命中括号内任一选择器。更糟的是，:is() 会提升整个选择器的优先级，可能意外覆盖本意想低权的样式。
立即学习“前端免费学习笔记（深入）”；
-
:where()优先级为 0，适合兜底重置，但不减少匹配节点数 - 真正有效的简化是砍掉中间层，比如给
a加class="nav-item-link"，直接用.nav-item-link - 若必须依赖结构（如 Markdown 渲染内容），用
article :is(h2, h3, h4)比article h2, article h3, article h4更紧凑，且只算一次祖先查找
哪些“看起来安全”的写法其实很危险
很多人觉得加了 class 就万事大吉，但 .sidebar .content .post .title 这种“全 class 路径”依然糟糕——它没减少匹配步骤，只是把标签名换成 class 名，浏览器照样从右往左查所有 .title，再逐个验证四层父级是否存在对应 class。
-
* + p是隐形杀手：每次插入新节点都要重查所有兄弟节点 -
html body div div div p这种“防篡改”写法反而让引擎多走三步无意义的标签匹配 - 动态生成的 class（如 BEM 的
.block__element--modifier）没问题，但若配合.block .block__element使用，就退回了冗余层级
复杂点在于：没有绝对“禁止”的语法，只有上下文里是否值得承担那几微秒的代价。最容易被忽略的是，样式计算开销在首屏不明显，但在 SPA 页面切换、表单校验高亮、甚至 prefers-reduced-motion 媒体查询切换时，会突然暴露出来。
