@use 替代 @import 是因后者破坏作用域隔离、引发全局污染，而 @use 强制命名空间访问、支持私有成员和安全透传；@forward 用于样式透传并控制可见性；需用 dart sass、注意工具链兼容性及团队协作规范。
为什么 @use 替代了 @import？
Sass 官方在 1.23.0 版本后正式弃用 @import，核心原因是它破坏了作用域隔离：所有被 @import 的变量、混合宏（@mixin）、函数会全局污染，容易引发命名冲突和意料外的覆盖。而 @use 默认只暴露命名空间下的成员，比如 colors.$primary，不加前缀就访问不到，强制你意识到来源。
实操建议：
- 新项目必须用
@use，老项目迁移时优先改入口文件（如main.scss），再逐个清理子模块里的@import -
@use只能出现在文件最顶部，且不能放在嵌套规则或@if条件块里 - 如果某个模块只提供变量/函数但不需要生成 CSS（比如工具函数库），
@use是唯一安全方式；@import会把它的 CSS 内容也塞进来
@forward 怎么做“样式透传”而不暴露实现细节？
@forward 不是导入，而是“转发”——它把另一个模块的成员重新导出，让上游使用者像直接用了那个模块一样，但中间层可以控制哪些东西可见、是否重命名、是否加前缀。
常见使用场景：
- 构建设计系统入口文件（如
_index.scss），统一@forward所有基础模块：@forward 'colors' with ($primary: #3b82f6 !default); - 隐藏内部模块名：用
@forward 'utils/breakpoints' as bp-*;，下游就能写@include bp-max('md') {...}，不用知道 breakpoint 实际在utils/下 - 避免重复编译：多个组件都依赖
_mixins.scss，与其各自@use，不如由布局层统一@forward一次，下游只@use布局层
如何避免 @use 导致的命名冲突和冗长前缀？
默认情况下 @use 'buttons' 要通过 buttons.button-variant() 调用，确实啰嗦。但 Sass 提供了明确的简化手段：
- 用
as *拆包：@use 'typography' as *;→ 直接用$font-size-lg，但仅限于无冲突时，慎用 - 用
as name缩短命名空间：@use 'components/card' as card;→card.shadow-sm比card.shadow-sm更短（实际就是缩写） - 模块内用
private前缀隐藏：声明$_internal-value: 12px;（下划线开头），@use后不会被外部访问到 - 别在多个
@use中引入同名变量——Sass 不报错，但后引入的会静默覆盖前一个，调试时极难发现
兼容性与构建链路中容易忽略的坑
Node Sass 已停止维护，@use 和 @forward 仅支持 Dart Sass（即 sass npm 包）。如果你还在用 Webpack + sass-loader，确认版本：
-
sass-loader≥ 12.0 +sass≥ 1.33.0 才完整支持 - Vite 默认用 Dart Sass，但若手动配置了
css.preprocessorOptions.sass.additionalData，注意它会在每个文件顶部注入内容，可能破坏@use的“必须位于顶部”规则 - VS Code 的 Live Sass Compiler 插件不支持
@use，换用 “Sass” 官方插件（by Syler） - CI 环境里如果用
npm ci，确保package-lock.json锁的是 Dart Sass，不是旧版 Node Sass
真正麻烦的不是语法转换，而是团队协作时有人忘了删 @import，或者在 @forward 后又手写 @use 引入同一模块——Sass 不禁止，但会导致变量重复定义警告，且 CSS 输出可能多一份重复样式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
