结论：函数封装计算、mixin封装样式、变量管理配置，三者分工明确才能提升复用性；混用如用if()替代@if会导致逻辑失效。
直接说结论：靠函数封装计算逻辑、用 mixin 封装样式行为、用变量管配置项，三者分工明确才能真正提升逻辑复用性；混用或错配（比如该用 @if 的地方写 if()）反而会让逻辑“看似存在却实际失效”。
什么时候该写 Sass 函数，而不是 mixin？
函数只返回值，不输出 CSS；它适合做纯计算、查表、条件判别这类“无副作用”的事。比如断点值查找、颜色明度调整、单位换算。
- ✅ 正确场景：
breakpoint("md")返回768px，供@media或clamp()使用 - ✅ 正确场景：
lighten($color, 10%)计算新颜色，但不生成任何规则 - ❌ 错误场景：试图用
if($theme == "dark", #111, #fff)控制整套暗色模式样式——它只能换一个值，无法删掉 light 专属的整块规则 - ⚠️ 注意：
if()是函数，@if是指令；前者不能控制是否生成 CSS 块，后者才可以
为什么 mixin 里不该硬编码断点值或颜色？
硬编码会让 mixin 失去复用基础。一个 @mixin responsive-font 如果写死 @media (min-width: 768px)，那它就只能用于中屏，没法适配新设计规范。
- ✅ 正确做法：接收断点名参数，内部调用
breakpoint($bp)查值，如@mixin responsive-font($min-bp: sm, $max-bp: lg) - ✅ 正确做法：颜色类参数默认读变量，如
@mixin btn-variant($bg: $color-primary)，既可覆盖也可继承 - ⚠️ 容易踩坑：在 mixin 中写
@if map-has-key($breakpoints, $name)再生成媒体查询——这其实该由调用方控制，否则 mixin 职责过重、难以组合 - ⚠️ 性能提示：Sass 编译时解析 mixin，嵌套太深或循环太多会拖慢构建，优先用简单参数组合替代复杂内部逻辑
@use 后变量/mixin 找不到？关键在命名空间和 @forward
不是代码没写，而是访问路径断了。@use 默认隔离作用域，所有暴露项必须显式声明或导入。
立即学习“前端免费学习笔记（深入）”；
- ✅ 必须做：
_mixins.scss里写了@mixin flex-center，就得加@forward "mixins" as flex-*;或@forward "mixins" with ($flex-gap: 1rem); - ✅ 调用时写全命名空间：
@include layout.flex-center();，不能省略layout. - ❌ 常见错误：在
main.scss中@use "mixins"，然后直接写@include flex-center()—— 编译报Undefined mixin - ⚠️ 路径陷阱：Sass 不自动补
.scss，但会找_mixins.scss；别写成@use "mixins.scss"或漏掉下划线
最常被忽略的一点：函数和 mixin 的复用价值，不在于“写得多”，而在于“改得少”。一旦某个 $breakpoints map 或 $color-tokens 变量被多个模块 @use，那它的结构稳定性就决定了整个样式系统的可维护上限——宁可多花十分钟理清 token 层级，也不要图快在三个文件里各自定义一套 $spacing-xs。
