<p>@warn 和 @error 仅在 Sass 编译阶段生效，@warn 输出警告但继续编译，@error 则中断编译；应将废弃逻辑封装进带 legacy- 前缀的 @function 并返回 map，配合 PostCSS 扫描模板，确保提示精准到文件行号。</p>
@warn 和 @error 不是运行时工具，它们只在 Sass 编译阶段起作用——编译一结束，警告和错误就消失了。想靠它们“拦截 HTML 中的 class 使用”或“让浏览器弹窗提醒”，完全行不通。
什么时候该用 @warn 而不是 @error
核心区别就一条：@warn 打印提示但继续编译；@error 直接中断编译、不生成 CSS 文件。
- 用
@warn提醒“这个 mixin 已计划下线，请尽快迁移”，给团队缓冲期 - 用
@error阻止明显非法输入，比如传入负数做边框宽度：@if $border-width - 别在公共函数里滥用
@error，否则下游项目一调用就崩，CI 构建失败率飙升 -
@warn的字符串支持插值，比如@warn "你传入的 #{$color} 不在主题色列表中";，比纯静态文本有用得多
@warn 在哪些场景下会静默失效
它看起来很可靠，但实际落地时一堆漏网之鱼：
- VS Code Live Server 或直接双击打开 HTML——没走 Sass 编译流程，
@warn根本不会触发 - CI 脚本用了
sass --quiet或把 stdout 重定向到文件（如> /dev/null），警告被吞掉 - 废弃逻辑写在纯 CSS 类里（比如
.old-header { ... }），而没封装进@function或@mixin，@warn压根感知不到 - 开发者保存 SCSS 后没看终端输出，或者清屏太快，警告一闪而过
如何让 @warn 真正被看见、被响应
不能只靠“打印一句话”，得把它嵌进可执行路径里：
立即学习“前端免费学习笔记（深入）”；
- 把废弃行为收口到
@function，比如legacy-text-center()，强制所有调用都经过它——@mixin不返回值，没法链式控制，不推荐 - 函数名带
legacy-前缀，IDE 补全时就能意识到“这是旧的”，比注释更早介入开发流程 - 返回一个 map（如
(text-align: center)）而不是直接输出 CSS，方便后续统一替换成新 utility class 生成逻辑 - 搭配 PostCSS 插件（如
postcss-html）扫描 HTML/Vue 模板里的硬编码类名，弥补@warn管不到模板层的缺陷
真正难的从来不是写一句 @warn，而是确保它出现在开发者必须经过的路径上，并且输出的信息足够具体——比如指出哪个文件第几行调用了废弃函数，而不是只说“已废弃”。否则，它就只是编译日志里一行没人读的噪音。
