深层嵌套选择器导致浏览器匹配变慢，因CSS从右往左匹配，需回溯检查祖先节点；安全深度上限为3层，应采用BEM命名避免结构依赖，并用工具在CI阶段拦截高特异性、多层复合等性能雷区。
为什么深层嵌套选择器会让组件变卡
浏览器匹配 CSS 是从右往左的，.card .header h2 不是先找 .card，而是先遍历所有 h2 元素，再逐个向上检查是否在 .header 内、再是否在 .card 内。DOM 节点越多，回溯路径越长，尤其在组件频繁挂载/卸载（比如 React 列表渲染）时，样式计算会成为明显瓶颈。
常见错误现象：getComputedStyle() 调用变慢、滚动卡顿、DevTools 的 “Layout” 阶段耗时突增；更隐蔽的是：哪怕你只改一个 class，浏览器也要重跑整个选择器匹配链。
- 安全深度上限是 3 层，如
.card__title✅，但.card .content .meta time❌ - 避免用标签名锚定结构：
article section h2比.article-title慢一个数量级，且模板一改就失效 - 组件内慎用
:nth-child()或:has()——它们无法被索引，每次 DOM 变动都触发全量扫描
用 BEM 命名替代结构依赖
BEM 不是“多写几个下划线”，而是把“我在哪”变成“我叫什么”。.search-form__input--error 不依赖父容器是否存在，也不怕 div 换成 section，浏览器直接哈希查类名，0 回溯。
实操要点：
立即学习“前端免费学习笔记（深入）”；
- 块名必须带业务语义：
.user-profile-card✅，.card❌（易与其他组件冲突） - 元素名不叠加父级：
.user-profile-card__avatar✅，.user-profile-card__card-avatar❌（冗余且难维护） - 修饰符只表达状态或变体：
.button--loading✅，.button--large-red-shadow❌（耦合视觉，不可复用） - 避免在组件内混用 BEM 和后代选择器：
.modal .close-btn应统一为.modal__close
哪些选择器在组件里最危险
组件常被复用、动态插入，低效选择器的影响会被放大。以下几类在组件作用域内要立刻干掉：
-
[data-testid="submit"]这类属性选择器：无索引，每次都要遍历全部节点；测试用属性应只用于 JS 查询，别写进生产 CSS -
* + .item这类通用兄弟选择器：强制全量扫描，组件列表渲染时开销爆炸 -
.list > li > a子选择器虽比后代快，但仍是层级依赖；直接用.list-item-link更稳 -
div#main这种标签+ID 组合：ID 本身已唯一，加div只增冗余匹配成本
构建时能自动发现的性能雷区
靠人眼 review 几百行 CSS 不现实。用工具在 CI 阶段拦截问题更可靠：
- 启用
stylelint规则：selector-max- specificity（建议 ≤ 10）、selector-max-compound-selectors（建议 ≤ 3） - PostCSS 插件
postcss-sorting可强制按性能排序：把.btn放前面，div p span直接报错 - Webpack 构建后用
critical提取首屏组件 CSS 时，会自动警告含:nth-child或[type]的规则——这些几乎从不该出现在关键样式中
真正容易被忽略的，不是“要不要优化”，而是组件 CSS 往往和 JS 逻辑解耦，样式作者看不到它在 200 行列表里被重复计算了 200 次。性能问题总在高频复用处爆发，而不是第一次写的时候。
