@error 在 sass 编译阶段中断流程，不作用于 css 层；仅校验变量/参数合法性，需前置检查类型，不支持 node sass 4.x 以下，不可用于拦截 css 无效值。
为什么 @error 在 Sass 中不阻止 CSS 编译失败？
它其实会——但只在 Sass 解析阶段报错并中断，不会等到 CSS 输出后才生效。很多人误以为加了 @error 就能“捕获运行时逻辑错误”，其实它只是提前终止编译流程，且只对 Sass 语法层有效。CSS 层面的无效声明（比如 color: invalid-value;）根本不会触发 @error，因为那已经过了 Sass 处理阶段。
怎么用 @error 检查变量或函数参数合法性
典型场景：你写了一个颜色工具函数，但传入了非颜色值，希望立刻报错而不是生成无意义的 CSS。
- 必须放在函数体、mixin 或条件块内部，不能裸写在顶层
- 检查逻辑要前置，比如在计算前验证
$color是否是颜色类型：@if not (type-of($color) == 'color') { @error 'Expected a color, got #{$color}'; } - 字符串插值用
#{$var}，别漏掉#和大括号，否则报错信息里显示的是字面量$var - 错误信息里避免拼接未定义变量，否则 Sass 会先因变量未定义而报另一个错
@error 和 @warn 的关键区别在哪
@warn 只打印警告，编译继续；@error 是硬中断，整个编译失败，终端直接退出并返回非零状态码——这对 CI/CD 流水线很重要。
- CI 脚本里依赖 Sass 编译结果时，必须用
@error才能阻断后续部署步骤 -
@warn适合提示“这个用法过时了”，@error适合“这个值完全非法，无法继续” - 两者都不影响 CSS 输出内容本身，它们只作用于 Sass 编译过程
容易被忽略的兼容性与调试陷阱
Sass 4.0+ 才支持 @error（LibSass 3.5+、Dart Sass 全版本），Node Sass 4.x 及更早版本不识别，会直接报语法错误。
立即学习“前端免费学习笔记（深入）”；
- 确认当前环境：运行
sass --version，输出含dart-sass或libsass版本号 - Webpack + sass-loader 用户要注意：loader 默认吞掉
@error的原始错误堆栈，需配置sassOptions: { quietDeps: false }并确保sourceMap开启才能准确定位到出错的@error行 - 错误信息里别写敏感路径或动态值（如用户输入），Sass 不做转义，可能暴露项目结构
@error，而是把它当成 CSS 校验器用——它管不了属性值是否合法，只管 Sass 变量、函数调用、控制流这些“编译前”的事。真要拦截 font-size: 2rem; 这种写法是否超出设计系统规范？得靠 PostCSS 插件或自定义 lint 规则。 
