@debug 在 Sass 编译时未输出，是因为它仅向终端或构建工具日志打印信息，不会出现在浏览器控制台；常见原因包括未查看终端日志、使用旧版 Dart Sass、被引入文件未触发编译等。
为什么 @debug 在 Sass 编译时没输出？
因为 @debug 只在编译阶段向终端（CLI）或构建工具日志中打印信息，**不会出现在浏览器控制台里**。如果你在 VS Code 里点“实时预览”或用 Live Server 打开 CSS 文件，是看不到 @debug 输出的——它早就在 Sass 编译成 CSS 的那一刻完成了使命。
常见误操作：
- 用
npm run dev启动但没看终端窗口滚动的日志 - 用了不支持
@debug的旧版 Dart Sass（低于 1.3.0） - 在
@import或@use的被引入文件里写了@debug，但主入口没触发编译（比如只改了未被引用的文件）
@debug 能输出什么类型的数据？
它支持任意 Sass 值：数字、字符串、颜色、列表、映射、布尔值，甚至函数返回结果。但要注意：Sass 会自动展开嵌套结构，对深层嵌套的 map 可能输出过长，反而难读。
实操建议：
- 调试单个变量直接写
@debug $color-primary; - 想确认类型用
@debug type-of($value); - 拼接提示文字时用插值：
@debug "Expected color, got: #{$value}"; - 避免对整个
$theme-map直接@debug，优先提取关键键：@debug map-get($theme-map, 'breakpoints');
和 @warn、@error 的关键区别在哪？
三者都输出到终端，但行为完全不同：
-
@debug：仅日志，不影响编译流程，可大量使用 -
@warn：输出黄色警告，编译继续，适合“可能有问题但还能跑”的场景（如过时的 mixin 参数） -
@error：红色报错，**立即终止编译**，适合强制校验（如必填参数缺失）
别用 @warn 替代 @debug 来查中间值——它会干扰 CI/CD 日志过滤，且部分构建工具默认抑制警告。
真实项目中怎么高效用 @debug 查逻辑分支？
复杂条件判断（比如响应式断点计算、主题色派生）最容易出错。与其猜哪条分支生效，不如在每个 @if 分支开头加一句 @debug。
示例：
@if $mode == light {
@debug "Applying light theme";
background-color: #fff;
} @else if $mode == dark {
@debug "Applying dark theme";
background-color: #1a1a1a;
} @else {
@debug "Unknown mode: #{$mode}, fallback to light";
background-color: #fff;
}
注意点：
- 插值
#{$mode}必须用引号包裹，否则编译报错 - 如果
$mode是 null，@debug会输出null，而不是空字符串 - 上线前不用手动删——多数构建流程（如 Webpack + sass-loader）默认不启用
--verbose，@debug就不输出
真正容易被忽略的是：当多个 @debug 连续触发时，它们的执行顺序严格按源码位置，但终端日志可能因缓冲延迟而错乱。如果看到输出顺序反常，加个 @debug "—— step 1 ——"; 做分隔更可靠。
