该用 @error 而不是 @warn 的关键判断标准是：参数错误是否导致生成的 css 完全不可用，如颜色名拼错、z-index 键不存在、断点值为 null 等必须用 @error。
什么时候该用 @error 而不是 @warn
关键判断标准只有一条：这个参数错误是否会导致生成的 CSS 完全不可用？比如颜色名拼错、z-index 键不存在、断点值为 null——这些情况必须用 @error，否则编译照常输出错误样式，上线后才暴露问题。
常见错误现象：写了 @if $color == null { @error "Color is required" }，但编译仍通过。这不是指令失效，而是 $color 实际是未定义（undefined），不是 null；Sass 中 null 是一个特殊值，而未声明变量、空字符串 ""、空 map () 都不等于它。
- 检测变量是否存在：用
variable-exists("color") - 检测 map 是否含某键：用
map-has-key($colors, $color) - 检测列表长度：用
list-length($sizes) > 0
@error 在 mixin 参数校验中的典型写法
在封装 @mixin responsive-bg($breakpoint, $color) 这类工具时，@error 应放在逻辑最前端，避免后续计算浪费资源。
实操建议：
- 先校验
$breakpoint是否在预设 map 中：@if not map-has-key($breakpoints, $breakpoint) { @error "Unknown breakpoint: #{$breakpoint}. Available: #{map-keys($breakpoints)}." } - 再校验
$color类型是否合法：@if type-of($color) != "color" { @error "Expected a color, got #{type-of($color)}: #{$color}." } - 插值内容必须确保已定义，否则会先报“undefined variable”，再报你的
@error，掩盖真正意图
CI/CD 环境下 @error 的行为要点
@error 会令 Dart Sass 编译进程以非零退出码终止，这正是 CI 工具（如 GitHub Actions、GitLab CI）将其识别为构建失败的依据。这是预期行为，不是 bug。
但要注意：
- 某些旧版构建脚本会忽略 stderr，导致
@error输出被吞掉，只看到“build succeeded”假象——需检查日志是否包含Error:前缀行 - 若你只想提醒而不阻断（比如提示某个参数即将废弃），请改用
@warn，并确认构建工具未静默屏蔽（如 sass-loader 需设verbose: true） - 错误信息里避免嵌套调用函数：
@error "Valid values: #{map-keys($valid-states)}"没问题，但@error "Try #{to-upper-case($state)}"若to-upper-case()未定义，会先爆函数错误
容易被忽略的编译时机陷阱
@error 发生在 Sass 编译早期，此时所有变量和 map 都已完成解析，但它**无法捕获运行时 CSS 行为错误**，比如 calc(#{$val} + 10px) 中 $val 单位缺失，这种问题要靠 lint 或浏览器 DevTools 发现。
更隐蔽的是：如果你在 @use 模块中触发 @error，而主文件用 @forward 暴露该模块，错误堆栈可能指向 _index.scss 而非真实出错的子文件——调试时得顺着 @use 链路逐个排查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
