@debug用于sass编译期调试，输出变量和表达式值，支持所有原生类型，需开启--trace等调试模式，不生成css，常见于@mixin、@function中验证中间值。
怎么在Sass里用@debug打印变量和表达式
@debug只在编译阶段输出信息，不会生成任何CSS，本质是给开发者看的日志。它适合在写混合宏（@mixin）、函数（@function）或条件逻辑（@if）时确认中间值是否符合预期。
常见错误是把它当console.log用——比如插在@media块里却没看到输出，其实是因为编译器默认不显示@debug（尤其在某些构建工具中）。必须确保编译器开启了调试模式：
- 命令行用
sass时加--trace参数：sass input.scss --trace - Webpack +
sass-loader需配置implementation并启用logger，否则静默丢弃 - VS Code插件（如Live Sass Compiler）默认不支持
@debug，得切到CLI
示例：检查颜色亮度计算是否越界
@function contrast-color($color) {
$lum: lightness($color);
@debug "Input color:", $color, "Lightness:", $lum; // 输出一行带空格的调试信息
@return if($lum > 50%, black, white);
}
@debug输出的内容能包含哪些类型
支持所有Sass原生类型：颜色、数字、字符串、列表、映射、布尔、null，甚至函数返回值。但不能直接打印CSS规则块、选择器或未定义变量——后者会报错中断编译。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑是误把CSS属性值当纯字符串处理：
-
@debug "margin: #{$val}";→ 输出字符串字面量，不是计算后的值 - 正确写法：
@debug "computed margin:", $val;（$val要是已计算的数值或带单位的长度） - 嵌套映射要展开打：
@debug "config map:", map-get($config, breakpoints);，不能@debug $config;（会输出(breakpoints: ...)这种不可读结构）
性能上无影响——@debug在解析阶段就被剥离，不影响最终CSS体积或渲染。
为什么@debug有时不输出，或者输出位置混乱
根本原因是Sass编译器按源码顺序执行，但@debug输出位置取决于它所在的上下文层级，而非CSS生成顺序。比如在@each循环里多次调用，输出顺序严格对应循环迭代次序；但在嵌套@include中，输出顺序由调用栈决定，可能穿插在其他文件的@debug之间。
典型干扰场景：
- 多个
@import文件都有@debug，输出混在一起难定位 → 改用带前缀的标识：@debug "[header] font-size:", $size; - 使用
@use后，被@use的模块里@debug默认不透出 → 必须在@use语句后加with或改用@forward显式暴露 - 某些IDE内置编译器（如CodePen的Sass预处理器）完全忽略
@debug→ 只能靠CLI验证
替代@debug的轻量调试手段有哪些
当@debug受限于环境无法使用时，可临时把值“泄露”进CSS注释，肉眼可见且不破坏样式：
-
/* DEBUG: #{$var} */—— 简单直接，但污染输出，上线前得手动删 - 用
@warn代替：@warn "Fallback triggered for #{$selector}";，强制显示且带文件行号，但会触发警告提示 - 对复杂逻辑，拆成独立
@function单独测试，用CLI跑小样例：sass -s "hsl(200, 100%, 50%)"验证颜色函数
真正麻烦的是跨文件作用域和异步计算——比如@function里调用了另一个模块的@function，而那个函数又依赖@use注入的配置。这时候@debug只能告诉你“这里错了”，但查不到上游哪一步算歪了。得一层层往前加断点，而不是指望一次输出全貌。
