@debug仅在编译成功执行到该行时输出，遇语法错误、未定义变量等会提前中断编译而无任何输出；需先解决红色报错、配置构建工具verbose模式，并确保写在有效作用域内。
终端根本没执行到@debug这行
@debug 不是“万能探针”，它只在编译流程走到那一步时才触发。一旦前面存在语法错误、未定义变量或类型不匹配，Sass 编译器会在 @debug 之前就报错退出，你自然看不到任何输出。
- 常见现象：保存文件后终端只显示红色报错（如
Undefined variable "$color"或Invalid CSS after "$size: 16px": expected "}", was ";"），但没有 @debug 行——说明它压根没运行 - 典型误操作：
$color: #ff0少了分号 → 编译中断 →@debug $color永远不会执行 - 真正该做的：先解决终端里第一行红色错误，再加 @debug；别指望靠它来定位语法问题
sass-loader 或构建工具默认吞掉了 @debug
@debug 默认输出到 stderr，而多数构建工具（尤其是 webpack 的 sass-loader）会静默丢弃它，除非显式开启 verbose 模式。
- Webpack 项目：必须在
sass-loader的sassOptions中设verbose: true，否则@debug被完全过滤 - Vite 项目：
css.preprocessorOptions.sass.verbose并非标准配置项，实际需靠 CLI 参数或插件行为，推荐改用sass --trace命令行验证 - VS Code Live Sass Compiler 插件：它不走 Dart Sass 官方 CLI，而是封装了自己的编译器，完全不支持 @debug —— 这不是你代码的问题，是插件能力缺失
@debug 写法或位置导致输出无效
@debug 对上下文敏感，变量作用域、调用时机、甚至输出格式都可能让它“看起来没生效”。
- 在
@if或@each块内调试时，@debug $var必须写在变量已声明且可访问的作用域内；写在条件外却引用局部变量，会直接报Undefined variable - 嵌套 map 或 list 时，
@debug $breakpoints只显示顶层结构，看不出md键是否被覆盖，应改用@debug map-get($breakpoints, md) - 插值必须加引号：
@debug "value: #{$val}"合法，@debug value: #{$val}会编译失败 - 如果
$val是null，Dart Sass 1.30+ 会明确输出null，旧版可能静默跳过——别误以为“没输出”就是指令失效
你以为在看 CSS，其实根本没进编译阶段
很多人盯着浏览器 DevTools 或生成的 CSS 文件找 @debug 输出，这是方向性错误。@debug 只向终端 stderr 打印原始值，和最终 CSS 内容无关，也不参与样式生成。
- 它不会出现在 .css 文件里，也不会以注释或 data-* 形式注入 HTML
- 它不等价于 JavaScript 的
console.log，没有运行时环境，不能在浏览器控制台看到 - CI/CD 流程中若未配
--verbose或未捕获 stderr，@debug 也会彻底消失，容易误判为“功能失效”
真正卡住人的点往往不是 @debug 本身，而是混淆了「编译失败」和「输出不可见」——前者是语法或语义错误，后者是环境或写法问题。确认终端有红色报错，就别急着加 @debug；确认构建工具已开 verbose，就别怀疑变量值没传进去。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
