@error用于SCSS中强制中断编译并抛出明确错误提示，需前置校验、用字符串拼接提供位置/原因/修复建议，避免在@import旧语法、@function或未调用模块中使用；@warn则用于非阻断式警告，适合提示弃用项。
SCSS里怎么用@error中断编译并抛出明确提示
当变量缺失、参数非法或配置冲突时，@error是唯一能强制停止编译并输出可读错误的指令。它不返回值，也不支持条件嵌套——只要执行到，编译立刻终止。
常见误用是把它放在混合宏（@mixin）末尾试图“兜底”，但实际应前置校验：
@mixin button-size($size) {
@if not map-has-key($button-sizes, $size) {
@error "Unknown button size '#{$size}'. Allowed: #{map-keys($button-sizes)}";
}
font-size: map-get($button-sizes, $size);
}
- 错误信息必须是字符串字面量或拼接结果，不能是未定义变量（否则报更底层的解析错误）
- 不要在
@each循环里频繁触发@error，一次就够了——重复报错不会叠加，但会掩盖真正问题点 - Webpack + sass-loader环境下，
@error会直接中断构建，终端显示红字，便于CI拦截
什么场景该用@warn而不是@error
@warn只打印黄色警告，编译继续，适合向使用者提示“你可能没注意到这个行为变化”。比如库升级后旧参数弃用：
@mixin flex-center($direction: row) {
@if $direction == horizontal {
@warn "Deprecated: use 'row' instead of 'horizontal' for $direction.";
}
display: flex;
justify-content: center;
flex-direction: $direction;
}
- 警告不会阻断流程，所以不能用来防御性检查关键依赖（比如
$theme-color未定义） - 多次
@warn同一内容会被去重，避免控制台刷屏；但不同消息仍会逐条显示 - Vite 项目中，
@warn输出在浏览器控制台看不到，只出现在终端构建日志里
如何让@error和@warn信息对用户真正有用
报错不是为了甩锅，而是帮调用方快速定位。有效信息至少包含三要素：错误位置、原因、修复建议。
立即学习“前端免费学习笔记（深入）”；
- 别写
@error "Invalid value"——要写@error "Invalid $radius value '#{$radius}' in @include border-radius(). Expected number or 'none'." - 用
type-of()判断类型比@if $var == null更可靠，因为null在SCSS里是关键字，而空字符串、0、false都可能被误判 - 避免在
@function里用@error，函数内报错会导致调用处样式丢失且无提示；应在调用前用@if+@warn提醒
为什么@error在@import链里容易失效
SCSS的@import（尤其旧语法）是文本拼接，不是模块加载。如果@error写在被@import的文件里，但该文件从未被实际使用（比如只定义了未调用的@mixin），它根本不会执行。
- 现代项目应改用
@use，它按需加载，且@error会在@use语句执行时立即触发 -
@use "utils" as u;之后再@include u.button-size(invalid)，错误才真正生效 - 用
sass --watch时，修改含@error的文件会触发重编译，但错误仅在首次使用该功能时出现——这点常被忽略
最易被绕过的其实是作用域：@error只能在当前作用域生效，跨@function或@mixin边界传递错误需要显式返回状态码，再由上层处理。
