@extend易致CSS难维护，因静态复制选择器引发权重突变、跨模块污染、冗余组合及编译体积暴增；应优先用%placeholder、避免跨模块继承、慎用嵌套上下文，并依场景选@mixin或@extend。
为什么 @extend 有时反而让 CSS 更难维护
直接用 @extend 复制选择器样式，看似省代码，实则容易触发意料外的层叠和覆盖。Sass 编译时会把被继承的选择器“复制”进所有调用它的地方，一旦基类选择器权重变高（比如从 .btn 升级成 .btn.is-primary），所有 @extend 它的地方都会同步升级权重——而你未必意识到。
- 避免跨模块
@extend：不要在组件 A 的文件里@extend组件 B 的私有占位符（如%flex-center），除非它们明确属于同一设计系统层 - 优先用
%placeholder而非真实类名：写%text-emphasis，而不是.text-emphasis，防止编译后无用类名泄露到 CSS 中 - 警惕嵌套上下文：在
.card { .title {@extend %text-emphasis;} }里使用@extend，会导致最终生成的 CSS 出现.card .text-emphasis这类冗余组合，而非复用原有规则
@extend 和 @mixin 到底该选哪个
核心区别不在“能不能复用”，而在“要不要共享选择器”。@extend 是选择器合并，@mixin 是声明复制。当你需要多个不相关的选择器共用同一套样式逻辑（比如 .btn、.link、[role="button"] 都要带焦点轮廓），@extend 编译后体积更小；但只要涉及动态参数（颜色、间距、断点），必须用 @mixin。
- 能用
%placeholder+@extend的场景：固定文字大小、统一阴影、标准化过渡属性 - 必须换
@mixin的场景：传入$color参数、根据$size计算 padding、内联媒体查询 - 混合用法可行但需克制：先用
@mixin生成基础样式块，再用%placeholder抽出其中不变部分供@extend
编译后 CSS 体积暴增？检查 @extend 是否跨了层级
Sass 对 @extend 的解析是静态的，但它会把所有匹配的选择器一股脑合并。如果一个 %clearfix 被 20 个组件引用，而其中 3 个组件本身又在媒体查询里，编译结果可能生成几十行重复的 clear: both 声明——尤其当基类本身含复杂伪类或属性选择器时。
- 运行
sass --watch时加--style=expanded，直接看编译输出，比猜更准 - 用
@at-root隔离上下文：在媒体查询块内慎用@extend，必要时先@at-root提出来再继承 - 检查 sourcemap：如果浏览器开发者工具里看到某条样式来自多个 SCSS 文件，大概率是
@extend横向扩散导致的
如何安全地重构旧项目加入 @extend
老项目里满屏 .btn-primary、.btn-secondary，想抽公共样式？别急着全局替换。先确认这些类是否真有语义一致性——比如 .btn-primary 在表单页是蓝色，在弹窗里却是绿色，那就不是“继承”问题，而是命名/设计系统断裂。
立即学习“前端免费学习笔记（深入）”；
- 从原子类开始：只对
%sr-only、%visually-hidden这类无业务语义的辅助类用@extend - 禁用通配继承：禁止写
@extend .btn，必须显式定义%btn-base并让所有按钮类主动继承它 - 留好回滚钩子：在
_base.scss里保留原始类定义注释，例如// legacy: .btn still works, but prefer @extend %btn-base
真正麻烦的从来不是语法会不会用，而是搞清哪些样式本就不该被“继承”——比如带业务状态的类名（.is-loading、.has-error），它们的含义依赖上下文，硬继承只会让调试时更难定位来源。
