深层嵌套和通配符是CSS选择器性能的两大“静默杀手”：4层+选择器如.header .nav .menu .item a:hover从右向左匹配，导致回溯激增，style recalculation时间暴涨3倍起；*强制全量DOM扫描，[type="text"]等属性选择器无法哈希加速，均严重拖慢FCP。
深层嵌套和通配符是 CSS 选择器性能的两大“静默杀手”，不是加载慢，而是 style recalculation 阶段卡住首次绘制（FCP）——尤其在移动端或 DOM 节点超 2000 时，.header .nav .menu .item a:hover 这类 4 层+选择器会让样式计算时间暴涨 3 倍起。
为什么 .a .b .c .d 比 .d 慢得多
浏览器匹配 CSS 选择器是从右往左的：先找所有 a:hover，再逐层向上验证父级是否满足 .item、.menu 等。DOM 越大，右侧节点越多，无效回溯越严重。
- 每多一层嵌套，匹配失败路径就指数增长；4 层嵌套在低端 Android 设备上实测比单类名慢 3 倍以上
-
div p（后代选择器）比div > p（子选择器）更危险：它不设层级上限，需跨任意深度搜索 - DevTools 的 Performance 面板中若
Recalculate Style占比高，且堆栈里频繁出现matchRules，基本可锁定为嵌套过深 - Sass/Less 中无节制嵌套（如
.card { .header { .title { ... } } }）会自动生成这类高危选择器，但开发者常意识不到
通配符 * 和属性选择器为何不能“只用一次”
* 不是“看起来无害”，而是强制全量 DOM 扫描；[type="text"] 或 [class^="icon-"] 也无法被哈希索引加速，每次都要字符串比对。
-
* { box-sizing: border-box; }在 5000+ 节点页面中，初始样式计算耗时增加 40–60ms -
input[type="text"]应替换为.form-input；[data-id]可改用.js-item[data-id]缩小作用域 -
:not(.valid) input这类否定伪类 + 类型组合，会让浏览器放弃快速匹配路径，退化为全量扫描 - 重置样式别写全局
*，改用窄作用域：article * { margin: 0; }或显式列举body, h1, p, ul, li { margin: 0; }
怎么改才真正有效：BEM + :where() + 关键 CSS 分离
不改 HTML 结构、不加 JS，靠命名和现代 CSS 特性就能降权提速。
立即学习“前端免费学习笔记（深入）”；
- 把
.card .header .title改成.card__title（BEM），消除层级依赖，匹配路径从 3 步减为 1 步 - 需要限定作用域时，用
:where(.card) .card__title替代.card .card__title：功能不变，优先级降为 0 - 旧项目难全量重构？至少给最外层容器加
data-component="card"，然后用[data-component="card"] .title替代深度后代选择器 - 首屏关键样式必须提取并内联进
<head><style>；其余 CSS 改用<link rel="preload" as="style" href="non-critical.css" onload="this.rel='stylesheet'">
容易被忽略的三个真实陷阱
很多人改了选择器却没见效，问题常出在这些隐蔽环节：
-
@import出现在首屏 CSS 文件里：它会阻塞后续规则解析，且无法并行下载，FCP 直接多等一个 RTT - 动态插入节点后调用
querySelector(".header .nav .item")：JS 查询也受 CSS 选择器结构影响，嵌套越深，查找越慢 - 用了
content-visibility: auto却保留* { ... }：隐藏区域虽不渲染，但通配符仍参与初始 CSSOM 构建，开销照旧
