选择器嵌套过深会降低性能并损害可维护性。css从右向左匹配，超4层如.container .sidebar .item .title span显著增加样式计算开销；bem等规范推荐扁平化命名如.card__title而非依赖dom层级，提升复用性、可调试性与迁移性。
选择器嵌套过深会导致浏览器重排重绘变慢
CSS 选择器是从右向左匹配的，.container .sidebar .item .title span 这类深度超过 4 层的选择器，会让浏览器在每次样式计算时遍历大量 DOM 节点。尤其当页面存在数百个 .title 元素时，每个都要向上逐层验证父级是否满足全部条件，CPU 时间明显增加。
- Chrome DevTools 的 Rendering 面板中可观察到
Layout阶段耗时上升 - 在低端设备或长列表页（如商品瀑布流）中，滚动时容易出现掉帧
- 搭配
will-change: transform或动画时，样式无效或触发意外重排
嵌套选择器让 CSS 复用性和可维护性急剧下降
深度嵌套常出现在预处理器（如 Sass）中，例如 &__header &__title &__icon 展开后生成 .card__header .card__title .card__icon —— 这种写法看似语义清晰，实则把结构强耦合进样式里。
- 组件迁移困难：把
.card拆成独立模块时，.card__header .card__title无法单独复用 - 修改 HTML 结构即失效：把
<h2 class="card__title"></h2>改成<div class="card__title"> <h2>，样式就丢了</h2> <li>BEM 建议用 <code>.card__title而非.card__header .card__title，就是为避免这种依赖 - 多个类似深度选择器共存时（如
.post .meta .published和.post-content div.meta time.published），优先级相近，!important使用频率被动上升 - VS Code 的 CSS Peek 功能对深层嵌套支持弱，跳转常停在错误层级
- 运行时通过
getComputedStyle(el)查看样式时，无法反推是哪条规则命中
调试时难以定位样式来源和冲突点
开发者工具里看到一条生效样式是 article.post-content div.meta time.published，你得先确认当前 time 元素是否真的在 div.meta 内、该 div 是否属于 .post-content、这个 article 又是不是 .post 类型……路径越长，人工验证成本越高。
.btn {
padding: 8px 16px;
}
/* ❌ 避免 */
.article .content .section .header .title h1 {
font-size: 24px;
}
/* ✅ 推荐 */
.article-title {
font-size: 24px;
}实际项目中，超过 3 层的纯类名嵌套（不含伪类、属性选择器）基本没有性能豁免理由；如果必须表达上下文关系，优先用 BEM 的修饰符（.list--compact .list__item）或数据属性（[data-context="admin"] .user-badge），而不是靠 DOM 层级“猜”结构。
立即学习“前端免费学习笔记（深入）”；
