@extend 在 CSS 组件库中易引发选择器爆炸、样式污染与调试困难，仅应限用于无语义的纯功能类（如 %sr-only），禁用于语义化组件类或含媒体查询/伪类的规则；推荐以 @mixin 或 HTML 多类组合替代。
为什么 @extend 在 CSS 组件库中容易出事
直接用 @extend 扩展基础布局，最常导致选择器爆炸、样式污染和调试困难。它不是“复用”，而是“复制选择器链”，一旦基础类名被多处 @extend，编译后 CSS 里会出现大量重复、嵌套过深的规则，比如 .btn-primary 和 .card-header 同时 @extend 了 .flex-center，结果所有用到 .flex-center 的地方都带上了一堆无关的父级上下文。
常见错误现象：Invalid CSS after "...": expected "{", was ";"（其实是语法没问题，但 Sass 因循环依赖或深度嵌套提前报错）；或者浏览器 DevTools 里点开一个元素，发现某条样式来自几十行外、完全不相关的文件。
- 只对**无语义、纯功能类（utility class）** 使用
@extend，例如.sr-only、.visually-hidden、.clearfix - 绝对不要
@extend带语义的组件类（如.button、.modal）或带 BEM 修饰符的类（如.button--large） - 如果基础布局类本身含媒体查询或伪类（如
@media (min-width: 768px)或:hover），@extend会把整块规则复制进去，极易引发响应式错乱
Sass 中替代 @extend 的更稳方案
真正可维护的扩展，靠的是抽象 + 组合，而不是继承。Sass 提供了比 @extend 更可控的机制：
- 用
@mixin封装可配置的布局逻辑，比如@mixin flex-center($direction: row)，调用时明确传参，不污染全局选择器 - 用
%placeholder替代普通类名做@extend目标——它不会输出 CSS，只在被@extend时才生成，能避免无意暴露样式钩子 - 对基础布局，优先定义成独立的工具类（如
.d-flex、.justify-content-center），通过 HTML 多类组合实现扩展，而非 Sass 层继承
示例：用 %flex-center 替代 .flex-center
立即学习“前端免费学习笔记（深入）”；
%flex-center {
display: flex;
justify-content: center;
align-items: center;
}
<p>.card-header {
@extend %flex-center;
}
这样编译后只有 .card-header 有 flex 样式，不会额外生成 .flex-center 类。
当必须用 @extend 时，怎么控制副作用
有些遗留项目或设计系统规范强制要求“继承式写法”，那就得硬控边界：
- 基础布局类必须是单一层级、无嵌套、无媒体查询、无伪类，命名加前缀如
%layout-flex-center，和业务类严格区隔 - 禁止跨模块
@extend，即components/_button.scss不能@extendlayout/_grid.scss里的东西，除非该 layout 文件明确声明为 “public extendables” - 用
@at-root防止嵌套污染：@at-root .btn { @extend %flex-center; }，确保生成的选择器不带父级上下文 - 每次
@extend后，手动检查编译输出的 CSS，确认没有意外出现的长选择器链（如.sidebar .card .header .flex-center）
组件库升级时 @extend 最容易翻车的点
团队协作中，没人会特意告诉你“我改了 %reset-styles”，但只要有人在某个新组件里 @extend %reset-styles，而你之前也用了，那你的组件就悄悄继承了对方新增的 margin/padding/box-sizing 规则。
- 所有被
@extend的占位符必须文档化，写清用途、适用范围、是否允许修改 - CI 流程里加入 Sass 编译后 CSS 行数对比告警，突然增长 30% 以上大概率是
@extend泛滥 - 升级 Sass 版本前，务必测试
@extend行为变化——Sass 4.x 对嵌套@extend的处理比 3.x 更严格，老代码可能直接编译失败
真正难的不是写对一行 @extend，而是所有人对“什么算基础”“什么算稳定”有一致预期。没共识的情况下，越想省事，后期越要花十倍时间定位样式冲突。
