在引入 @layer 之前，覆盖组件库样式通常依赖提高选择器权重或追加 !important。前者让选择器越来越长，后者则把优先级问题推迟到下一次覆盖。@layer 提供了一种按声明顺序而非选择器权重来组织样式的方式，但它的一个重要行为常常让人困惑：带 !important 的声明，其层优先级顺序与普通声明相反。如果不理解这一点，在分层样式中使用 !important 可能得到与直觉完全相反的结果。
设想一个常见的生产场景：项目引入了一个第三方组件库，组件库的样式被打包进一个名为 vendor 的层，项目自身的覆盖样式放在 overrides 层。按照 @layer 的规则，后声明的层优先级更高，因此 overrides 中的普通声明会覆盖 vendor 中的普通声明。这个机制让覆盖变得直观。但当某条覆盖规则加上 !important 后，情况反转：vendor 层中的 !important 声明反而会压过 overrides 层中的 !important 声明。
要理解这个反转，需要先看清 CSS 级联的完整排序过程。CSS Cascading and Inheritance Level 5 规范定义了级联排序的多个步骤。对于作者样式，浏览器会先按来源和重要性分组：普通声明与 !important 声明被分成两个不同的“桶”。在同一个桶内，再按层顺序、选择器权重、出现顺序依次比较。关键点在于，普通声明的层顺序是“后声明的层优先”，而 !important 声明的层顺序是“先声明的层优先”。
级联排序：重要性优先于层顺序
级联排序的第一步是确定声明的重要性。带 !important 的声明与普通声明属于不同的重要性级别，浏览器会先处理所有 !important 声明，再处理普通声明。这意味着，任何 !important 声明都会优先于任何普通声明，无论后者位于哪个层、选择器权重多高。
在重要性分组之后，浏览器才在组内比较层顺序。对于普通声明，层顺序按声明顺序排列，后声明的层优先级更高；对于 !important 声明，层顺序反转，先声明的层优先级更高。这个反转并非偶然，而是规范有意设计的结果，目的是让 !important 的语义保持一致：!important 表示“这条声明很重要，应该覆盖普通规则”，但在多个 !important 冲突时，需要有一个明确的裁决顺序。
规范将 !important 的层顺序设为普通层的逆序，这样做的效果是：如果组件库的 vendor 层先声明，项目覆盖层 overrides 后声明，那么 vendor 层中的 !important 声明会优先于 overrides 层中的 !important 声明。这看起来像是组件库的样式“反客为主”，但实际上是规范为了保持 !important 的“高优先级”语义而做的权衡。
层顺序的建立：声明顺序决定优先级
@layer 的层顺序通过两种方式建立：一是使用 @layer 语句规则一次性声明多个层的名称，例如 @layer theme, layout, utilities;，此时后列出的层优先级更高；二是通过 @layer 块规则或 @import ... layer(...) 按出现顺序隐式建立。一旦层顺序确定，后续再向某个层追加规则不会改变该层在顺序中的位置。
在组件库覆盖场景中，通常的做法是：
@layer vendor, overrides;
@layer vendor {
.btn {
background-color: blue;
color: white;
}
}
@layer overrides {
.btn {
background-color: green;
}
}这里 vendor 层先声明，overrides 层后声明，因此 overrides 中的普通声明会覆盖 vendor 中的普通声明，按钮背景色最终为绿色。这个行为符合直觉，也是 @layer 的主要价值：让覆盖逻辑变得清晰，不再依赖选择器权重。
!important 反转：一个具体例子
现在给上面的例子加上 !important。假设组件库的样式和覆盖样式都使用了 !important：
@layer vendor, overrides;
@layer vendor {
.btn {
background-color: blue !important;
}
}
@layer overrides {
.btn {
background-color: green !important;
}
}按照普通声明的直觉，overrides 层后声明，似乎应该覆盖 vendor，但实际结果是按钮背景色为蓝色，因为 !important 声明的层顺序是反的：先声明的 vendor 层优先级更高。
这个例子展示了 !important 反转的直接后果。如果项目覆盖样式依赖 !important 来强制覆盖组件库，而组件库内部也使用了 !important，那么覆盖可能失效。更糟糕的是，这种失效很难通过检查选择器权重或层顺序来发现，因为表面上看 overrides 层确实在 vendor 层之后。
未分层样式与层的交互
除了层内样式，CSS 还允许存在未分层的样式。规范规定，未分层的普通声明优先于所有层内的普通声明；而未分层的 !important 声明则相反，优先级低于所有层内的 !important 声明。这个规则进一步强化了 !important 的反转特性。
在组件库覆盖场景中，如果项目在层外写了一条普通规则：
.btn {
background-color: red;
}这条规则会覆盖 vendor 和 overrides 层中的普通声明，即使它的选择器权重很低。这为覆盖组件库提供了一种简单方式，但也会带来隐患：如果层外的普通规则过多，层的意义就被削弱了。
对于 !important 声明，情况相反：层外的 !important 声明优先级最低，会被任何层内的 !important 声明覆盖。这意味着，如果项目试图用层外的 !important 来强制覆盖组件库的 !important，将不会生效。
嵌套层与 revert-layer
@layer 支持嵌套，例如 @layer framework { @layer layout { ... } }。嵌套层的顺序规则与平铺层类似，但需要将嵌套层视为一个整体。在比较两个嵌套层时，先比较外层层的顺序，再比较内层层。!important 的反转规则同样适用于嵌套层。
与层相关的另一个关键字是 revert-layer，它可以将当前层的声明回滚到上一层。在覆盖场景中，revert-layer 提供了一种显式放弃当前层声明的方式。例如，如果 overrides 层中的某条规则不想覆盖 vendor 层的值，可以使用 revert-layer。但需要注意，revert-layer 对 !important 声明的行为也受层顺序反转的影响，使用时需要仔细验证。
对比：!important 与层内覆盖的权衡
为了更清晰地理解不同覆盖策略的差异，下面用表格对比几种常见做法。
| 策略 | 覆盖组件库普通样式 | 覆盖组件库 !important 样式 | 选择器权重影响 | 维护成本 |
|---|---|---|---|---|
| 提高选择器权重 | 可行，但需要精确匹配 | 可行，但需要更高权重 | 高 | 高，选择器易膨胀 |
| 使用 !important | 可行，但会污染 | 可行，但依赖顺序 | 低 | 中，容易失控 |
| 使用 @layer 分层 | 可行，后层覆盖前层 | 不可行，前层覆盖后层 | 低 | 低，结构清晰 |
| 层外普通声明 | 可行，优先于层内 | 不可行，被层内 !important 覆盖 | 低 | 中，破坏分层 |
从表格可以看出，@layer 在覆盖普通样式时最有效，但面对 !important 时反而成为障碍。因此，在设计覆盖策略时，应优先避免在组件库和覆盖样式中使用 !important，而是依靠层顺序来管理优先级。
生产实践：如何避免 !important 反转带来的冲突
在真实项目中，组件库可能已经使用了 !important，或者团队习惯用 !important 解决紧急问题。要避免冲突，可以采取以下措施：
- 约定层顺序：在项目入口处用
@layer语句明确声明所有层的顺序，并确保覆盖层位于组件库层之后。 - 避免在覆盖样式中使用 !important：如果组件库的样式没有 !important，那么覆盖层中的普通声明就足够。
- 审查组件库的 !important 使用：如果组件库内部使用了 !important，需要评估是否可以通过定制主题或调整层顺序来规避。
- 使用层外普通声明作为后备：对于必须覆盖的少量属性，可以在层外写普通声明，但要注意这会破坏分层结构，应限制使用。
- 使用 CSS 变量：如果组件库支持 CSS 变量，优先通过变量定制，而不是覆盖属性值。
可观测性与调试
在开发过程中，如果发现样式没有按预期生效，可以使用浏览器开发者工具的“计算样式”面板查看最终生效的声明及其来源。Chrome DevTools 会显示声明所属的层以及是否被覆盖。通过检查层顺序和 !important 标记，可以快速定位问题。
一个常见的调试场景是：覆盖层的样式没有生效，检查后发现组件库的样式带有 !important，而覆盖层没有。此时，要么给覆盖层也加上 !important，但要注意层顺序反转，要么移除组件库的 !important。
边界与限制
@layer 的 !important 反转行为在 CSS Cascading and Inheritance Level 5 规范中定义，并已在主流浏览器中实现（自 2022 年 3 月起广泛可用）。但需要注意，规范中某些特性（如 revert-layer）在早期实现中可能不稳定，使用时需检查浏览器兼容性。
此外，@layer 并不能解决所有样式冲突问题。例如，当组件库的样式通过内联样式（style 属性）设置时，@layer 无法覆盖，因为内联样式属于作者样式中的最高优先级。此时需要借助 !important 或 JavaScript 来修改。
结论
CSS @layer 提供了一种基于层顺序的样式管理机制，但 !important 会反转层优先级，导致先声明的层反而具有更高优先级。在组件库覆盖场景中，理解这一反转是避免样式冲突的关键。最佳实践是避免在分层样式中使用 !important，依靠层顺序和普通声明来管理覆盖，同时利用浏览器开发者工具进行调试。
以下流程图总结了 @layer 与 !important 的决策路径：
flowchart TD
A[开始] --> B{声明是否带 !important?}
B -- 否 --> C[普通声明组]
C --> D[按层顺序比较: 后层优先]
D --> E[选择器权重比较]
E --> F[出现顺序比较]
B -- 是 --> G[!important 声明组]
G --> H[按层顺序比较: 前层优先]
H --> I[选择器权重比较]
I --> J[出现顺序比较]
F --> K[确定最终值]
J --> K
在图中，普通声明和 !important 声明被分成两条路径，层顺序的比较方向相反。这个决策过程解释了为什么在分层样式中，!important 的层优先级与普通声明相反。