CSS Nesting 与级联：嵌套规则如何影响选择器权重与层叠顺序

从组件库样式覆盖说起

假设你正在维护一个基于 BEM 命名的组件库，组件根节点类名为 .card，内部标题为 .card__title。使用方想覆盖默认标题颜色，通常会写：

.card__title { color: red; }

这条规则的选择器权重是 (0,1,0)，与组件库内部规则相同。若两者都匹配，后加载的样式胜出，覆盖能否成功取决于样式表加载顺序。现在改用 CSS Nesting 重写组件库：

.card {
  .card__title { color: blue; }
}

浏览器会将其扁平化为 .card .card__title，权重变为 (0,2,0)。使用方若仍用 .card__title 覆盖，即使加载顺序靠后也会失败，因为权重更低。这就是嵌套带来的优先级陷阱：视觉上更紧凑的代码，却悄悄提高了选择器权重，改变了层叠结果。

CSS Nesting 模块（CSS Nesting Module Level 1）允许将样式规则嵌套在另一规则内部，子规则的选择器相对于父规则。浏览器解析时，嵌套规则会被展开为等效的普通规则，但展开过程中选择器权重的计算方式与 :is() 伪类一致，即取选择器列表中最高的一项。这一机制与 Sass 等预处理器的“编译后拼接”不同，后者只是文本替换，权重按最终选择器计算，而原生嵌套的权重规则更微妙。

嵌套规则的扁平化与权重计算

规范定义，嵌套规则可以隐式使用后代选择器，也可以显式使用 & 嵌套选择器。例如：

.foo {
  color: red;
  .bar { color: blue; }
}

等价于：

.foo { color: red; }
.foo .bar { color: blue; }

这里 .bar 前自动补全了父选择器 .foo。若使用 &：

.foo {
  &:hover { color: blue; }
}

等价于 .foo:hover。& 可以出现在选择器的任意位置，例如 .featured & 表示 .featured .foo。

嵌套规则在 CSSOM 中通过 CSSNestedDeclarations 接口表示，但样式计算时仍按展开后的规则处理。关键点在于，& 的权重等价于 :is()，即取括号内选择器列表的最大权重。例如：

.foo, #bar {
  & .baz { color: red; }
}

展开后为 :is(.foo, #bar) .baz，权重为 (1,1,0)，因为 #bar 贡献了 ID 权重。即使 .foo 只贡献类权重，整个选择器也按最高权重计算。

嵌套层级与权重累积

嵌套层级越深，展开后的选择器包含的父选择器越多，权重自然累积。例如：

.a {
  .b {
    .c { color: red; }
  }
}

展开为 .a .b .c，权重 (0,3,0)。每层嵌套都增加一个类（或 ID、元素）的权重。这看似直观，但容易在不知不觉中抬高规则优先级，尤其是当父选择器本身包含 ID 或复杂列表时。

一个常见陷阱是：组件库作者为了模块化，将样式按组件层级嵌套，结果内部规则权重远超预期。使用方想用简单的类名覆盖，却因为权重不足而失败，只能被迫提高自己选择器的权重（如增加 ID 或 !important），形成恶性循环。

与级联层的交互

级联层（@layer）是控制层叠顺序的机制，层顺序优先于选择器权重。嵌套规则可以放在层内，其权重计算不受层影响，但层顺序决定了不同层之间的优先级。例如：

@layer base, components, overrides;

@layer components {
  .card {
    .card__title { color: blue; } /* 展开后权重 (0,2,0) */
  }
}

@layer overrides {
  .card__title { color: red; } /* 权重 (0,1,0) */
}

由于 overrides 层在 components 之后，即使其规则权重更低，最终 color: red 也会生效。层顺序优先于权重，因此嵌套导致的权重提升在层内有效，但跨层时被层顺序覆盖。这为组件库提供了一种缓解方案：将覆盖样式放入更高优先级的层中，无需担心嵌套权重。

组件库场景：BEM 与嵌套写法对比

以商品卡片组件为例，传统 BEM 写法：

.card { /* 基础样式 */ }
.card__title { font-size: 1.2rem; }
.card__price { color: #333; }
.card--featured .card__title { color: gold; }

嵌套写法：

.card {
  /* 基础样式 */
  .card__title { font-size: 1.2rem; }
  .card__price { color: #333; }
  &.card--featured {
    .card__title { color: gold; }
  }
}

两者在样式计算上等效，但嵌套写法将相关样式聚合，减少了重复书写。然而，嵌套写法中 .card__title 的权重从 (0,1,0) 变为 (0,2,0)，.card--featured .card__title 从 (0,2,0) 变为 (0,3,0)。使用方若按 BEM 文档覆盖，会发现原有选择器失效。

下表对比了两种写法在权重、可维护性和覆盖难度上的差异：

维度	BEM 扁平写法	CSS 嵌套写法
选择器权重	类名组合，权重可控	嵌套自动增加权重，可能超出预期
样式组织	按块、元素、修饰符分散	按组件结构聚合，可读性好
覆盖难度	同权重下靠加载顺序	需更高权重或 !important
可维护性	修改需跨多处，易遗漏	局部修改方便，但层级过深难追踪
与级联层配合	可直接放入层	同样可放入层，但权重影响仍在层内

优先级陷阱与失败模式

嵌套最常见的失败模式是“权重意外升高”。例如，父选择器为 #app .card，嵌套子规则展开后包含 ID，权重极高，覆盖几乎不可能。另一种模式是“隐式后代选择器”造成的误匹配：

.card {
  :hover { color: red; }
}

未加 & 时，浏览器自动添加空格，解析为 .card *:hover，匹配所有悬停的后代元素，而非卡片本身悬停。这往往不是作者本意，且难以察觉。

此外，嵌套规则与 :is() 的权重一致性意味着，若父选择器列表包含高权重项，即使实际匹配的是低权重分支，整个规则的权重也按高权重计算。例如：

.card, #featured {
  .title { color: red; }
}

展开为 :is(.card, #featured) .title，权重 (1,1,0)。当元素只匹配 .card 时，规则权重依然包含 ID，导致其他 .title 规则难以覆盖。

可观测信号与诊断路径

生产环境中，若发现样式覆盖失效，应首先检查嵌套规则展开后的权重。浏览器 DevTools 的“计算样式”面板会显示实际生效的规则及其选择器，可看到展开后的形式。若规则被划掉，说明权重或层顺序不匹配。

另一个信号是样式在局部修改后意外变化：嵌套层级调整导致权重变化，影响其他组件。诊断时可临时禁用嵌套，改用扁平选择器对比，或使用 @layer 明确层顺序。

与 Sass 等预处理器的差异

Sass 等预处理器在编译时进行文本替换，嵌套规则直接拼接选择器，权重与手写扁平规则一致。原生 CSS 嵌套则按 :is() 规则计算权重，且由浏览器解析，无需构建步骤。这带来了兼容性差异：原生嵌套需要浏览器支持，而 Sass 产物是普通 CSS。

在团队协作中，若混用原生嵌套和预处理器，需注意权重行为不一致。例如，Sass 中 .foo { .bar {} } 编译为 .foo .bar，权重 (0,2,0)，与原生相同；但若使用 @at-root 或变量插值，结果可能不同。

适用边界与降级方案

CSS Nesting 已得到主流浏览器支持（自 2023 年 12 月起），但旧浏览器可能需要回退。降级方案是使用预处理器编译，或手动展开嵌套。在组件库中，建议控制嵌套深度不超过两层，并避免在父选择器中使用 ID。

若必须支持旧环境，可使用 PostCSS 插件（如 postcss-nesting）在构建时展开，但需注意其权重计算与原生规范一致。

总结

CSS Nesting 通过扁平化规则改变了选择器权重的计算方式，其 & 选择器权重等价于 :is()，导致嵌套层级直接叠加权重。在组件库场景中，这会使覆盖样式变得困难，但级联层可缓解跨层优先级问题。理解权重累积规则，控制嵌套深度，并利用 DevTools 验证展开结果，是避免优先级陷阱的关键。

flowchart TD
    A[编写嵌套 CSS] --> B[浏览器解析并扁平化]
    B --> C{是否使用 & 选择器?}
    C -- 是 --> D[按 :is 规则计算权重]
    C -- 否 --> E[自动添加后代选择器]
    D --> F[生成等效选择器]
    E --> F
    F --> G[参与级联比较]
    G --> H{是否在更高层?}
    H -- 是 --> I[层顺序优先，权重次之]
    H -- 否 --> J[按权重和顺序决定]
    I --> K[最终样式]
    J --> K