CSS @layer 与层叠优先级：现代 CSS 架构的有序管理

先理清：CSS 层叠优先级到底在比什么

每个前端项目做到一定程度，都会在“样式覆盖”这件事上摔几跤。可能你明明把按钮背景色写在组件文件的最后一个选择器里，刷新页面后看到却是另一个颜色。你顺着选择器权重往下查，发现一条写在更早的全局样式里的规则，它的选择器权重也一样。于是你开始加 !important，可后来你发现，连 !important 都开始互相打架了。

这背后不是某个人的代码写得不好，而是 CSS 层叠模型天生如此：当声明来源相同时，选择器权重和源码顺序决定了胜负。源码顺序恰恰是最脆弱的约束——构建工具调整了文件合并顺序，或者有人往全局样式里加了条新样式，页面就可能悄悄变了。

CSS @layer 就是为了改变这个局面而出现的。它把层叠优先级的管理从“后写者赢”变成了“显式声明谁赢”。这篇文章会详细聊 @layer 的用法、它如何影响层叠优先级，以及在真实项目中应该怎么落地。

@layer 是什么：一个顺序声明的分层容器

简单说，@layer 允许你把一组样式声明放进一个命名层，并提前定义层之间的顺序。后面声明的层，优先级高于前面声明的层。

@layer reset, base, components, utilities;

@layer reset {
  * {
    box-sizing: border-box;
  }
}

@layer base {
  body {
    font-family: system-ui;
  }
}

@layer components {
  .card {
    padding: 1rem;
  }
}

@layer utilities {
  .p-2 {
    padding: 0.5rem;
  }
}

第一行没有大括号，它只声明层的顺序。后面各层内部的规则，即使代码书写顺序看起来是打乱的，最终优先级仍然以第一行的顺序为准。这意味着你可以在文件里先写 components 层，再写 base 层，但实际层叠效果还是 base 在前、components 在后。

@layer 对层叠优先级的真实影响

要理解 @layer，首先要明白它只在作者样式内部重新划分了优先级。在普通样式（不带 !important）中，分层后的优先级从高到低大致是：未分层的作者样式、后声明的层、先声明的层、浏览器默认样式。为什么未分层样式优先于层内样式？你可以把它想象成一个没有声明在 @layer 里的“匿名层”，它被自动追加在所有显式层的最后面。这样设计是为了兼容既有代码：当项目还没有使用 @layer 时，原有样式不会被新引入的层提前压下去，迁移过程可以更平滑。这个细节非常关键，很多人会忽略。

看一个例子：

@layer base, components;

@layer components {
  .btn { background-color: blue; }
}

@layer base {
  .btn { background-color: red; }
}

最终按钮的背景色是蓝色，因为 components 层排在 base 层之后，层内的普通规则拥有更高优先级。

真正容易让人迷惑的是 !important。它会让层的优先级顺序反转：在关键声明中，先声明的层反而优先于后声明的层，而未分层的 !important 规则又压过所有层内的 !important。

@layer base, components;

@layer base {
  .btn { background-color: red !important; }
}

@layer components {
  .btn { background-color: blue; }
}

最终背景是红色。因为 base 层的 !important 规则优先级高于 components 层的普通规则，哪怕 components 层排后面也一样。如果两层都加 !important，那么 base 层的 !important 更靠前，依然会赢。

这里可以整理成一张简单的参考表：

这张表不需要死记，但明确它会让你调试时少走很多弯路。尤其是 !important 反转，几乎是所有人都会栽一遍的地方。

几个容易绕晕的细节：层顺序、作用域与 !important

第一个常见误区是认为 @layer 层块的书写顺序决定了优先级。实际上优先级只看入口处的层顺序声明。比如下面的代码，结果同样会是绿色：

@layer a, b;

@layer b { .box { color: green; } }
@layer a { .box { color: red; } }
/* 生效的是 b 层，颜色为 green */

第二个误区是对“层”这个词的想象。@layer 不是作用域，也不是样式隔离。两个层里都定义 .title，后层的 .title 还是会覆盖先层的 .title。它只解决优先级顺序，不解决类名碰撞。所以 BEM、CSS Modules 这些命名约束依然有存在的必要。

第三个误区是认为用了 @layer 就可以彻底扔掉 !important。在实际工程里，为了覆盖来自老代码的动态内联样式，或者与外部注入的样式对抗，important 仍然可能是最后手段。但它的使用频率应该被压到极低，一旦你发现自己要写很多 !important，多半是层的划分出了问题。

为什么要用 @layer：三个真实工程场景

第一个场景是第三方 UI 库的样式覆盖。很多项目会引入一个现成的组件库，然后重新定义它的主题。过去你得想办法让自己后续引入的样式“压住”库里的规则，一旦构建顺序变了就可能翻车。现在可以把库样式放进一个独立的层，并把它放在自己的基础层之前：

@layer reset, library, base, components, utilities;
@import url('vendor/library.css') layer(library);

注意 @import 需要放在样式表靠前的位置，但这条 layer(library) 语法在大多数目标浏览器上已经可用。这样一来，你在 components 层里写的覆盖样式永远比 library 层优先，跟文件加载顺序完全解耦。

第二个场景是多人协作的大型项目。团队里有人维护全局样式，有人写页面样式，有人写组件样式。如果没有分层约定，最常见的局面是：每个人都担心自己的样式被覆盖，于是不断往上堆选择器权重。最终形成一个谁也看不懂的优先级泥潭。引入 @layer 后，团队可以先在代码评审里约定好层序，然后把样式按职责放到对应层里，全局样式的优先级一目了然。

第三个场景是工具类与组件样式的共存。Tailwind 这类方案在今天很流行，它的核心机制是让工具类比组件类后出现，因此可以覆盖组件的默认样式。可是当你同时使用组件库和工具类时，两者之间谁先谁后又会变成新的问题。@layer 天然适合解决它：把组件库放入前层，把 utilities 工具类放在最后一个层，让工具类的覆盖能力变得稳定可预期。

@layer vs BEM、CSS Modules、Tailwind：谁取代谁？

不太准确的说法是“以后可以用 @layer 替代 BEM 或 CSS Modules”。它们解决的问题并不相同。BEM 处理的是类名命名和可读性，CSS Modules 处理的是局部作用域，Tailwind 是预先设计好的工具类体系，而 @layer 处理的是多个来源之间的层叠优先级。你完全可以在 BEM 结构中使用 @layer，也可以在 CSS Modules 项目里用 @layer 管理全局样式与组件的顺序。

理解这一点，你就不会把 @layer 当成银弹。它更像是一套通用的层叠秩序框架，能让其他方案在自己的轨道上更稳定地运行。

如何在现有项目中稳妥引入 @layer

不要试图一次完成全量迁移，这会很痛苦。推荐的做法是渐进式迁移。

第一步，先在样式入口处声明一个目录级的层顺序。哪怕是简单的三层，也比没有强：

@layer reset, base, utilities;

第二步，把 reset 或 normalize 样式包进最前面的层。如果项目里没有 reset，可以让 base 层承载全局元素的基础样式。

第三步，将第三方库的样式通过 @import layer(…) 或构建工具包裹到指定层，一般放在 reset 后、项目基础样式前。

第四步，将你真正想要覆盖库样式的业务样式放进更后面的层。比如 components 层和 utilities 层。

最后，留下一块未分层的样式区域，用于过渡期的临时修复。因为未分层样式优先级高于所有层，它为你提供了一个“退路”。但随着迁移深入，要定期检查并移除这些未分层样式，否则它们又会变成另一个隐藏的优先级黑洞。

经验提醒：迁移期尽量不要在分层样式内部使用 !important。一旦混入，优先级的反转会让你很难判断最终结果。先保持普通声明，等分层稳定后再处理个别必需场景。

项目实践中还有几个建议：

• 层顺序定义统一放在一个入口文件，最好一行写完，并让团队周知。
• 避免过度分层。层数超过 7 个，管理成本会明显上升。
• 在 CI 中加入样式对比测试，防止重构过程中出现意外覆盖。
• 至少在 Chrome、Firefox、Safari 最新版本上做一轮视觉回归。

结语：让优先级从“巧合”变成“设计”

CSS 的层叠优先级原本是“无组织的自然过程”，@layer 将它变成了可设计的接口。它并不能消除所有样式管理的复杂性，但它至少让你有机会在项目早期建立一套清晰的秩序。

如果你已经厌倦了在样式文件里反复寻找谁覆盖了谁，不妨从下一版本开始，为你的项目加上一个最小的层顺序声明。也许一周之后，你就会发现样式维护比以往可控得多。