@debug用于sass编译期调试，只向终端输出变量值、类型等信息，不生成css，不可替代console.log；适用于查变量值、类型、作用域及逻辑分支，需配合type-of()、map-get()等避免嵌套结构输出混乱。
什么时候该用 @debug 而不是 console.log
@debug 是 Sass 编译期指令，只在 CSS 生成前起作用，不会出现在最终 CSS 里，也不依赖浏览器环境。它适合查变量值、类型、作用域或计算逻辑是否符合预期——比如你写了 $font-size: rem-calc(16)，但编译后字体没变，这时候 console.log 根本看不到，因为还没到 JS 运行阶段。
常见错误现象：变量输出为空、类型是 number 却被当 string 拼接、@if 判断总走 false 分支——这些都得靠 @debug 把值“打出来”看。
- 只在开发时启用，生产构建前应删掉所有
@debug - 它会中断编译并抛出警告（不是报错），不影响 CSS 输出，但终端会清晰打印位置和值
- 不支持表达式求值，只能输出变量或字面量，例如
@debug $color + 10会报错，得先赋值再 debug
@debug 输出的值为什么看起来像乱码？
Sass 对某些类型做了简略显示，比如颜色值默认输出十六进制（debug: #333），但如果你定义的是 $c: rgba(0, 0, 0, 0.5)，@debug $c 可能输出 rgba(0, 0, 0, 0.5) 或 transparent（取决于上下文和 Sass 版本），容易误判。
更麻烦的是 map 和 list：嵌套过深时终端只显示第一层，比如 @debug $breakpoints 可能只输出 (sm: 480px, md: 768px)，但你实际需要确认 md 的值是不是被覆盖了。
- 用
type-of($var)配合@debug看真实类型：@debug type-of($var) - 对 map 逐层展开：
@debug map-get($breakpoints, md) - 注意 Dart Sass 从 1.30+ 开始对 null 值输出更明确（
null），旧版可能静默忽略
如何避免 @debug 污染终端日志？
多个文件、多个组件同时加 @debug，终端刷屏根本找不到关键信息。尤其配合 watch 模式，保存一次就打出十几行，反而掩盖真正的问题点。
- 加描述性前缀：
@debug '[typography] font-size:', $font-size - 用条件包裹，只在特定开关下触发：
@if $debug-mode { @debug 'grid cols:', $grid-columns; } - 不要在 mixin 或 function 内部无条件
@debug，除非你确定每次调用都要看——这会让复用逻辑变得脆弱 - VS Code 用户可装 “Sass Lint” 插件，自动高亮未删除的
@debug行
Dart Sass 与 Node Sass 的 @debug 行为差异
Node Sass（已停更）输出格式较简陋，路径显示不完整，且对自定义函数返回值有时不显示类型；Dart Sass（当前标准）输出带文件名、行号、列号，还支持多参数逗号分隔（@debug $a, $b, $c）。
一个典型坑：你在 Dart Sass 中写 @debug inspect($map) 能看到完整结构，但 Node Sass 不支持 inspect() 函数，直接报错。
- 升级到 Dart Sass 后，优先用
inspect($var)查复杂值，比裸@debug更可靠 - CI/CD 环境若仍用 Node Sass，
@debug可能被静默跳过，导致调试失效 - CI 日志里搜
DEBUG:不一定能匹配到，Dart Sass 默认前缀是Debug:（首字母大写）
@import 覆盖了，@debug 打出来的只是那一刻的快照，不代表它在真正使用时还是那个值。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
