@layer能替代90%的!important场景，因其按声明顺序而非选择器权重决定覆盖关系；需在入口CSS顶部统一声明层序（如@layer reset,base,vendor,…），后续各文件中同名layer自动归入对应优先级。
因为不靠堆选择器、不靠!important，也能让业务样式稳稳压过第三方库和基础组件——前提是把样式按逻辑分层，并控制好@layer的声明顺序。
为什么@layer能替代90%的!important使用场景
你写.btn { color: red; }被 UI 库的#app .ui-button.btn盖掉，不是因为你写得不够狠，而是权重战场已经失控。而@layer不比选择器长度，只看层声明顺序：只要把你的业务样式放进后声明的 layer，它天然覆盖前面所有同名规则，哪怕对方用了 ID 或内联 style（注意：内联样式仍高于所有@layer）。
常见误操作：
- 只在局部 CSS 文件里写
@layer components { ... }，却没提前统一声明层顺序，导致不同文件中 layer 优先级错乱 - 把第三方库样式直接引入 HTML 的
<link>，没走@import url("lib.css") layer(vendor);，结果它的规则落在匿名层，反而比命名层优先级还高 - 以为
@layer能改变 z-index 渲染层级——不能。@layer只决定“哪条 CSS 规则生效”，不影响定位上下文或 stacking context
如何正确声明 layer 顺序以避免意外覆盖
最稳妥的做法是在项目入口 CSS（如main.css）顶部一次性列出所有 layer 名称，用逗号分隔：
立即学习“前端免费学习笔记（深入）”；
@layer reset, base, vendor, components, utilities;
这行代码本身不写任何样式，只锚定优先级顺序：越靠后的 layer 优先级越高。之后你在任意文件中用@layer components { ... }写的规则，都会自动归入这个已定义的层，并获得对应优先级。
关键点：
- 必须是首次出现的
@layer语句决定顺序；后续同名@layer只是往该层注入样式，不改变排序 - 如果某处写了
@layer { .x { } }（匿名层），它会按出现位置参与排序，但无法被其他文件复用或对齐，极易引发不可控覆盖 - 第三方库建议统一导入到
vendor层：@import "antd.css" layer(vendor);，这样你就能确保components层永远能覆盖它
多人协作时怎么避免 layer 命名冲突和职责混乱
layer 名不是随便起的标签，它代表样式治理的契约。推荐按功能域划分，且全团队共用一套命名规范：
-
@layer reset：仅用于 Normalize / Reset，禁止放任何业务相关样式 -
@layer base：全局基础样式（body、h1、button:default等），不包含具体组件 -
@layer components：各业务组件的默认样式，每个组件一个文件，都包裹在@layer components里 -
@layer utilities：工具类（mt-4、text-center），必须最后声明，方便覆盖一切
切忌出现@layer home-page、@layer cart-module这类页面级 layer——它们破坏分层抽象，导致 layer 数量爆炸，失去可维护性。
浏览器兼容性和构建工具支持现状（2026年5月）
主流浏览器均已稳定支持：@layer在 Chrome 104+、Firefox 106+、Safari 17.4+ 中无需前缀。Edge 基于 Chromium，同样可用。
但要注意构建环节：
- Vite 5.0+、Webpack 5.80+、esbuild 0.19+ 原生识别
@layer，无需插件 - 旧版 PostCSS（如 postcss-preset-env @layer，需显式开启
cascade: true选项，否则会被直接删除 - SCSS 不支持
@layer语法（截至 Sass 1.77），若用 SCSS，必须把分层逻辑放在纯 CSS 文件中，或改用 CSS-in-JS 方案配合 layer 注入
真正容易被忽略的是：即使所有浏览器都支持，只要有一处样式漏进匿名层（比如某个组件库的style.css直接 link 进来），它就可能意外压过你精心设计的命名层——所以「全量分层」不是理想，而是底线。
