应避免超过3层嵌套、冗余父级及与BEM混用；宜用于作用域隔离、响应式覆盖或第三方组件修正；子选择器>性能优，+依赖顺序，~慎用于长列表；BEM应禁用嵌套，用修饰符替代；CSS Nesting需@nest显式声明且不支持跨规则。
什么时候该用嵌套选择器，什么时候不该用
嵌套选择器（如 .header .nav a、.card > .content）本身没有语法错误，但过度嵌套会显著拖慢 CSS 解析速度，尤其在低端设备或大型 DOM 树中。浏览器是从右向左匹配选择器的，.header .nav a 实际先找所有 a，再向上逐层验证父级是否满足条件——嵌套越深，回溯越多。
以下情况应避免嵌套：
- 超过 3 层深度（例如
.layout .main .section .title） - 仅为了“语义清晰”而加冗余父级（如
body .header nav ul li a） - 与 BEM 或 CSS-in-JS 方案混用时强行复刻 HTML 结构
真正需要嵌套的典型场景是：精确限定作用域（如模态框内按钮样式隔离）、响应式断点内局部覆盖、或第三方组件无法修改 class 名时做最小侵入式修正。
>、+、~ 这些组合器怎么选
不同组合器性能和语义差异明显，不能只看“能不能实现效果”：
立即学习“前端免费学习笔记（深入）”；
-
>（子选择器）：只匹配直接子元素，解析快、意图明确。适合结构稳定且层级严格控制的场景，例如.dropdown > .menu确保只影响一级菜单项 -
+（相邻兄弟）：只匹配紧邻的下一个同级元素。常用于表单提示、状态切换（如input:focus + .hint），性能好，但依赖 HTML 顺序 -
~（通用兄弟）：匹配之后所有符合条件的同级元素。灵活性高，但浏览器需遍历后续全部兄弟节点，慎用于长列表中（如h2 ~ p在含 50 个段落的页面里开销明显）
避免用 ~ 替代 JS 控制显隐；也别用 + 去“猜”不确定的 DOM 顺序——结构一变就失效。
嵌套与 BEM 的冲突怎么解
BEM 原则强调每个 class 都是独立、扁平、可复用的，而传统嵌套选择器天然依赖上下文，二者直接混合容易导致：
- 样式泄漏（
.button .icon意外影响其他地方的.icon） - 重构困难（改一个父 class 名，整片嵌套全崩）
- 开发者误以为“写了嵌套就不用写 BEM 子元素名”，结果出现
.card .title而不是.card__title
正确做法是：BEM 下基本不用嵌套选择器。如果真要限定范围，优先用修饰符（.card--compact .card__title）或命名空间（.legacy-form .form__input）。工具链如 Sass 的 & 符号可以生成 BEM 类名，但输出仍是扁平 class，不产生真实嵌套选择器。
.card {
&__title {
font-size: 1.2em;
}
&--compact &__title {
font-size: 1em;
}
}
编译后是 .card__title 和 .card--compact .card__title —— 后者虽含空格，但本质是两个独立 class 的组合，不是结构依赖型嵌套。
现代方案：CSS Nesting（@nest）能直接替代老写法吗
CSS Nesting 是原生支持的嵌套语法（Chrome 116+、Safari 17.1+、Firefox 124+），但它和预处理器嵌套有本质区别：它最终仍编译为标准选择器，且规则更严格。
- 只允许嵌套在规则体内，不能无限制缩进（
.a { .b { color: red; } }合法；.a .b { color: red; }不合法，必须用@nest） - 必须显式声明嵌套关系：
.a { @nest .b { color: red; } }编译为.a .b，而非.a.b - 不支持跨规则嵌套（无法从
.x内部跳到.y下写样式）
这意味着它更适合组织 BEM 式代码块，而不是替代旧式深层嵌套。上线前务必检查目标浏览器支持度，生产环境仍建议用 PostCSS 插件（如 postcss-nesting）做降级。
最易被忽略的一点：嵌套层级本身不增加 specificity，但生成的选择器长度会。比如 .modal .header .title 的 specificity 是 0-3-0，和手写的完全一样——性能损耗不在嵌套语法，而在最终选择器的复杂度和匹配路径长度。
