Sass中应优先用@mixin封装稳定不变的视觉契约（如transition-all），避免参数臃肿；慎用@extend以防选择器爆炸；按使用边界拆分文件而非类型；@use比@import更可控，需配合命名空间与合理@forward。
怎么用Sass的@mixin替代重复的CSS声明
直接复用样式块，而不是复制粘贴。比如按钮的圆角、阴影、过渡效果，在多个组件里反复出现时，@mixin就是最轻量的解法。
常见错误是把逻辑塞太满：一个@mixin button-base硬塞进颜色、尺寸、响应式断点，结果每次调用都得传七八个参数，反而更难维护。
- 只封装「稳定不变」的视觉契约，比如
@mixin transition-all固定写transition: all 0.2s ease;，不带具体属性名 - 颜色、尺寸这类易变参数，必须设默认值，且用语义化变量名：
@mixin button($bg: $primary, $radius: 4px) - 避免在
@mixin里嵌套@media——断点应由调用方控制，否则会污染组件的响应逻辑
@mixin flex-center {
display: flex;
justify-content: center;
align-items: center;
}
// 调用
.card {
@include flex-center;
}
Sass中@extend为什么常被误用
@extend本质是生成选择器合并，不是“继承”。它会让编译后的CSS选择器爆炸，尤其在大型项目里，一个.btn-primary被@extend十次，最终可能生成几十行冗余选择器。
典型误用场景：用@extend去复用工具类（如.text-center、.mb-2），结果导致CSS体积翻倍，且无法按需加载。
- 只对「语义明确、极少变动」的基础类用
@extend，比如.visually-hidden这种纯功能类 - 禁止跨模块
@extend：A模块的.card-header不能@extendB模块的.section-title，否则依赖关系失控 - 用
@debug检查输出：@debug "Extending #{$selector}";能帮你发现意外的继承链
如何拆分Sass文件才不会让@import变成性能黑洞
Sass 6.0+已弃用@import，但大量老项目还在用。问题不在语法，而在拆分逻辑：把所有变量/函数塞进_variables.scss，所有通用样式塞进_base.scss，最后全局@import——这会让每个页面都加载整套CSS，哪怕只用了一个按钮。
真正有效的拆分，是按「使用边界」而非「类型」来切：
- 组件级文件（如
_button.scss）只包含该组件自身样式 + 必需的@mixin，不引入无关变量 - 变量按作用域分层：
_theme-vars.scss（主题色、断点）、_component-vars.scss（仅按钮内部用的$button-padding） - 禁用深层嵌套
@import：A.scss@import "B"，B.scss又@import "C"——这样改C会导致A重编译，CI耗时飙升
为什么@use比@import更可控
@use强制命名空间，杜绝变量/混合宏冲突。比如两个不同模块都定义了reset()，用@import会覆盖；而@use "form" as form后，只能显式调用form.reset()。
但容易踩的坑是「过度隔离」：每个文件都@use "sass:math"，结果编译器反复解析同一份内置模块，拖慢构建速度。
- 只在真正需要的地方
@use，基础函数（如math.div）优先在根index.scss统一@use并@forward - 别用
@use "xxx" as *——这等于退化回@import的全局污染模式 -
@forward时加as重命名：把@forward "theme" as theme-vars，比裸露theme.$primary更清晰
拆分 Sass 最难的不是语法，而是判断「这个样式到底属于谁」：是组件自身？是设计系统层？还是临时业务逻辑？一旦归属模糊，复用就变成耦合，优化就变成负债。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
