混用 @mixin 和 @function 的核心问题是边界不清：函数应专注纯计算并做输入校验，mixin 应专注样式生成与上下文控制；二者须通过明确契约协作，而非嵌套调用或越界职责。
混用 @mixin 和 @function 本身不难维护，难的是没划清边界——把该由函数干的计算逻辑塞进 mixin，或让 mixin 承担本该由函数返回值驱动的样式分支，结果调用链变黑盒，改一处，三处破。
mixins 里硬写 function 调用，导致编译时行为不可见
常见错误现象：一个 @mixin button-style($size) 内部直接调用 scale-font($size)（一个返回 px 值的 @function），但没注释说明这个函数依赖 $font-sizes map；某天有人删了 map 里的 sm 键，编译不报错，但所有 @include button-style(sm) 输出的 padding 变成 0px。
根本原因：SCSS 编译器只校验语法，不校验函数返回值是否在预期范围内；@mixin 是样式生成单元，不是计算容器。
- 正确做法：把
scale-font()的调用提前到 mixin 参数层，比如@include button-style(scale-font(sm))，让调用方明确看到“这里传入的是计算结果” - 或改用参数约束：在 mixin 内部用
@if not map-has-key($font-sizes, $size)主动报错，而不是静默 fallback - 禁止在 mixin 主体中无 guard 地调用任意 function，尤其涉及 map-get、unit、type-of 等易出错操作
function 返回选择器字符串，被 mixin 拼接后破坏作用域
使用场景：想动态生成 BEM 子元素类名，写了 @function bem-child($block, $element) 返回 "#{$block}__#{$element}"，再在 mixin 里用 #{$selector} { ... } 包裹。
问题来了：这个 @function 返回的是字符串，不是真实选择器；如果 mixin 在嵌套上下文里调用（如 .card { @include with-header; }），而 with-header 内部又用了 bem-child("card", "title")，最终生成的却是全局 .card__title，而非 .card .card__title。
- 真正安全的做法：function 只做纯计算（如单位换算、颜色明度调整），不构造选择器；选择器拼接应由 mixin +
&完成 - 若必须动态生成选择器，请用
@at-root显式脱离嵌套，避免歧义 - 别让 function 返回带
.或#的字符串——那已经越界到 selector 构建层了
参数类型模糊导致 mixin 和 function 协作失效
典型错误：定义 @function px-to-rem($value)，期望输入数字（如 16），但有人传入 16px；mixins 调用它时没做单位剥离，结果输出 16px / 16 = 1px 这种无效 rem 值。
性能影响不大，但调试成本极高：你得顺着 @include responsive-padding(px-to-rem(16px)) → px-to-rem → 16px / $base-font-size 一路查，而编译器不会提示“你传了带单位的值”。
- function 必须做输入防御：用
if (unit($value) == "px") { $value: strip-unit($value); } - mixins 调用 function 前，优先用
type-of校验：比如@if type-of($size) != number { @error "button-size: $size must be a number"; } - 别依赖“大家都会传对”，而要靠声明式契约：每个 function 的
/** */注释里必须写@param $value — 数值，不含单位
最常被忽略的一点：mixins 和 functions 的复用粒度不同。function 是“值处理器”，应该小而确定；mixin 是“样式生成器”，天然带上下文。把两者强行耦合，等于让一个负责造砖的工人去指挥砌墙顺序——不是不能干，而是干完之后，谁也说不清墙歪了是因为砖不对，还是砌法错了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
