Sass 中 @import 因全局污染、重复编译和调试困难已被弃用，推荐改用 @use（按需加载+命名空间）和 @forward（可控转发），迁移需分层理清依赖并更新构建工具链。
为什么 @import 在 Sass 里越来越不推荐用
因为 @import 会把所有被导入文件的 CSS 规则无条件拼进当前文件，哪怕你只用其中一两个变量或 mixin，整个文件也照单全收——结果是重复编译、体积膨胀、调试困难。现代 Sass（v2.0+）已正式弃用它，改用 @use 和 @forward。
常见错误现象：Invalid CSS after "@import": expected 1 selector or at-rule, was "@use" —— 这说明你用了新版 Sass CLI 但还写老语法；或者样式突然重复出现，查来查去发现同一个 _mixins.scss 被五个地方 @import 了三次。
- 所有
@import "xxx"必须替换成@use "xxx"或@forward "xxx" -
@use是“按需加载 + 命名空间隔离”，@forward是“透传转发”，二者不能混用同一路径 - 旧版
@import "vars"默认会把vars.scss里的$color-primary直接注入全局；而@use "vars"后必须写vars.$color-primary才能访问
怎么把一堆 @import 文件安全迁移到 @use
不是简单替换关键字，关键在理清依赖流向：哪些是工具层（变量/mixin/function），哪些是组件层（按钮/卡片），哪些是页面层（home.scss）。迁移顺序应该是从底层工具开始，逐层向上。
使用场景：你有一堆散落的 _reset.scss、_typography.scss、_buttons.scss，全靠 @import 堆在 main.scss 里，现在想拆清楚又不破环现有样式输出。
立即学习“前端免费学习笔记（深入）”；
- 先建一个统一入口文件，比如
index.scss，里面只写@forward "base/reset"、@forward "base/typography"，不写@use - 把原
main.scss中的@import "_reset"改成@use "index" as base，然后用base.$reset-margin这类带命名空间的方式调用 - 如果某个组件（如
_card.scss）内部需要$spacing-sm，就单独@use "base"，而不是靠全局隐式注入
@forward 和 @use 的参数差异直接影响可维护性
@forward 不只是“转发”，它支持 as、hide、show 控制暴露范围，这是 @import 完全做不到的。比如你不想让下游直接改 $z-index-drawer，但又要提供 z-index("drawer") 函数——就得靠 @forward "zindex" hide $z-index-drawer。
性能影响：用 @forward "utils" show color-lighten 比 @use "utils" 再手动挑函数快，Sass 编译器能跳过未声明的函数解析。
-
@forward "mixins" as m-会让所有 mixin 前缀变成m-text-truncate() -
@forward "colors" hide $blue-50可防止下游误用未设计好的色值 - 不要在
@forward后再跟@use同一模块——会造成重复解析，Sass 会警告"xxx" has already been loaded
重构后 CSS 输出没变，但 source map 对不上怎么办
这是最常被忽略的一环：@use 和 @forward 改变了模块解析路径，DevTools 里点开样式可能跳转到 index.scss 而不是你真正编辑的 _buttons.scss。根源在于 source map 没有映射到原始文件，而是映射到了被 @forward 整合后的逻辑位置。
兼容性影响：老项目用 Webpack + sass-loader 时，默认不支持新语法，会卡在 Unknown rule @use。必须升级 sass-loader >= 12.0.0 并确认 implementation 指向 sass（而非 node-sass）。
- Webpack 配置里加
sourceMap: true和sourceMapContents: true，否则断点无效 - VS Code 用户装插件 “Sass”（Syler）而非 “SCSS”，后者不识别
@use语法高亮 - 如果用了
@use "src/styles/vars" as v，但编译报错说找不到路径，检查是否漏了includePaths或用了相对路径（@use "../vars"在不同层级下行为不一致）
