组件库样式覆盖自定义规则，因其实现多在document.head末尾注入且未分层，优先级“卡位”不可控；正确做法是用@layer显式包裹组件库样式并确保其声明顺序最晚，避免!important滥用。
为什么组件库样式总“压”过你的自定义规则
因为绝大多数组件库（如 Ant Design、MUI、Element Plus）的 CSS 是在 document.head 末尾或通过 JS 动态注入的，其样式默认落在「未分层」层中，而这个隐式层的优先级**介于你显式声明的 @layer 之间**——不是最低，也不是最高，而是“卡位”导致覆盖不可控。更糟的是，它们常混用 !important 或高特异性选择器（如 .ant-btn.ant-btn-primary:hover），进一步放大冲突。
@layer 声明顺序必须晚于组件库加载
关键点不在你写了多少层，而在于浏览器解析 @layer 的时机：它按源码顺序建立层栈，后声明的层优先级更高。所以如果你在 app.css 里写：
@layer base, components, overrides;
@layer components { /* 组件库样式被你主动收编 */ }
@layer overrides { /* 你的定制必须放在这里 */ }但组件库的 CSS 文件（比如 antd.css）是通过 <link> 引入且位于 app.css 之前，那它的规则就自动掉进「未分层」层，反而可能比你的 @layer components 更高——这违背初衷。
正确做法是：
立即学习“前端免费学习笔记（深入）”；
- 确保组件库 CSS **不直接引入**，改用
@layer显式包裹（需构建工具支持，如 PostCSS 插件或 Vite 的css.preprocessorOptions） - 若无法修改组件库源码，就在你的主 CSS 文件最顶部统一声明所有层，且把组件库对应的层放在**最后**：
@layer reset, base, vendor, app, overrides;→ 其中vendor层专门收容组件库规则 - 用
@layer vendor { @import "antd.css"; }（注意：原生 CSS@import必须在顶层，且仅支持同域）
覆盖组件库样式时别碰 !important，用层内嵌套更安全
很多人一遇到覆盖失败就加 !important，结果后续维护时发现：某个按钮颜色改不回来了，因为 !important 已经被组件库和你的代码反复叠加，权重失去意义。用 @layer 的本意就是替代它。
实操建议：
- 把定制规则写在最高优先级层（如
@layer overrides），而非在同层里靠后写——层内顺序只影响同层规则，跨层必须靠层声明顺序 - 避免写
@layer overrides { .ant-btn { color: red !important; } }；改成@layer overrides { .ant-btn.custom-primary { color: red; } }，再在 HTML 中加class="custom-primary" - 对动态类名（如 MUI 的
makeStyles生成的哈希类），用属性选择器锚定：@layer overrides { [class*="MuiButton-root"] { padding: 8px 16px !important; } }——这里!important仅用于突破 JS 注入样式的特异性，不是设计习惯
第三方库的 Shadow DOM 或 CSS-in-JS 怎么办
@layer 对 Shadow DOM 内部样式完全无效，也管不了 Emotion、Styled Components 这类运行时生成的 style 标签。它们各自维护独立的样式作用域。
能做的有限但明确：
- 对于 Shadow DOM：必须用
shadowRoot.querySelector+insertRule或adoptedStyleSheets手动注入，@layer不穿透 - 对于 CSS-in-JS：检查库是否提供
theme或classNamePrefix配置项，优先走官方定制通道；若不行，用!important+ 高特异性选择器兜底（例如div[data-emotion] .my-btn { ... }） - 永远不要假设
@layer能解决所有第三方样式问题——它只管「标准 CSS 文件注入流程」这一条路径
真正容易被忽略的点：层声明本身不会重排已解析的样式规则。如果组件库 JS 在页面加载后才调用 document.styleSheets[0].insertRule，那些规则永远不属于任何 @layer，只能靠传统手段应对。
