深层选择器让样式计算变慢，因浏览器从右往左匹配：先找所有a:hover，再逐级向上验证父级是否满足li→ul→.widget→.sidebar，DOM越大、候选越多、回溯越深，Style Recalc耗时越显著。
为什么深层选择器会让样式计算变慢
浏览器匹配 CSS 选择器是「从右往左」进行的。写一个 .sidebar .widget ul li a:hover，它不会先找 .sidebar，而是先抓页面里所有 a:hover，再逐个往上查：父级是不是 li？再往上是不是 ul？再往上是不是带 .widget 的元素？最后还要确认这个 .widget 是不是在 .sidebar 里。
DOM 越大，a:hover 候选越多，回溯路径越长，样式计算（Style Recalc）耗时就越明显。尤其在悬停、滚动、动画等高频重绘场景下，Chrome DevTools 的 Rendering 面板会直接标红这类规则为「潜在性能问题」。
三层以内是安全线，但得看右侧是否够具体
光数层级没用——div ul li a 是四层，但比 .nav-link:hover（一层）慢得多，因为前者右侧 a 太宽泛，后者右侧 .nav-link:hover 直接锁定目标。
- 优先用 class 作最右端，比如
.btn-primary、.card-title - 避免以标签名或通配符结尾：
div p、*[role="button"]、:not(.is-hidden) > * - BEM 中的
.menu__item--active是好例子；但若写成.menu .menu__item--active，就又退回两层嵌套，失去意义 - 伪类连用要警惕：
nav ul li a:hover::before实际是 5 层匹配，应改用.nav-link:hover::before
别靠肉眼改，用工具定位高成本规则
手动扫 CSS 文件容易漏掉隐藏的深坑。真实项目里，最常被忽略的是开发阶段看不出问题，等数据量上来、打开 DevTools 的 Rendering 面板才看到 Layout 抖动。
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome 或 Edge DevTools → Ctrl+Shift+P → 输入
Coverage→ 启动，刷新页面，看哪些 CSS 规则「命中率高 + 匹配路径长」 - 在 Styles 面板悬停某条规则，右侧点开
Matched CSS Rules，直接看到浏览器实际走的匹配路径 - 在构建流程中接入
postcss-selector-max-specificity，CI 阶段拦截 specificity > 10 或深度 > 3 的选择器 - Edge 和 Chrome 都支持
CSS Overview工具（F12 → More Tools → CSS Overview），能一键识别未使用、高特异性、深层嵌套的选择器
用变量和 contain 替代“结构条件传递”
很多深层选择器其实不是为了定位，而是为了表达「在某种上下文里才生效」，比如 .dark-theme .card .button。这种逻辑完全可以用更轻量的方式表达。
- 用 CSS Custom Properties：
:root { --button-bg: #333; }+.dark-theme { --button-bg: #eee; }+.button { background: var(--button-bg); } - 局部主题用
data-theme属性，而不是依赖全局 class 层级穿透，例如[data-theme="dark"] .button比.dark-theme .card .button少一层回溯 - 对富文本、弹窗等独立区域，加
contain: style layout paint，告诉浏览器：这部分样式变化不影响外部，跳过子树的样式计算 - 慎用
will-change：它只提示合成层优化，不减少样式计算本身；滥用反而增加内存压力
