sass 5.0+ 废弃 @import 是因其破坏模块化：全局作用域导致命名冲突、重复编译、无法选择加载、无命名空间；@use 实现作用域隔离，@forward 用于封装接口而非简单转发。
为什么 @import 在 Sass 5.0+ 里被标为 deprecated
Sass 官方从 v5.0 开始把 @import 标记为废弃，不是因为它不能用，而是它破坏了模块系统的可预测性：所有被 @import 的文件会全局合并作用域，变量、混合宏、函数一旦重名就静默覆盖，调试时根本分不清是谁污染了谁。
典型表现是：改了一个 _mixins.scss 里的 @mixin button，结果整个项目按钮样式突变，但控制台没报错，也找不到调用链。
-
@import会重复编译同一文件（比如多个文件都@import "vars"，$primary-color就会被解析多次） - 无法选择性加载——你想只用
reset不用typography？不行，全得 import 进来 - 不支持命名空间，
@import "utils"后，clearfix()和hide()都直接挂进全局，和第三方库撞名概率极高
@use 怎么替代 @import 实现真正隔离
@use 是模块化起点：每个文件默认私有作用域，必须显式暴露 + 显式引入，变量/混合宏/函数不会自动泄漏。
比如 _buttons.scss 里写 @forward "mixins" as button-*;，使用者就得写 btn.button-hover 才能调用，不会和别的 hover() 冲突。
立即学习“前端免费学习笔记（深入）”；
- 必须放在文件顶部，且一个文件只能有一个
@use同一路径（重复@use "foo"不会报错，但第二次无效） - 别名要用
as，不是from：@use "src/utils" as u;，之后用u.reset() -
@use不支持通配符导入，@use "vars" as *;是非法的——这是故意限制，逼你明确依赖 - 如果旧项目混用
@import和@use，Sass 会强制把@import全部提升到最前，可能引发变量未定义错误
@forward 的真实用途不是“转发”，是“组装包”
@forward 常被误解成“把 A 文件的内容转给 B”，其实它干的是“封装发布接口”：你在 index.scss 里 @forward "mixins"，等于对外声明“本模块提供这些 mixins”，实际实现可以藏在子目录深处，用户只认 @use "mylib" 这一个入口。
常见错误是把它当 @import 的平替——比如在 theme.scss 里 @forward "colors" 又 @forward "typography"，以为这样就能合并导出。但用户 @use "theme" 后，还是得写 theme.$font-size-base，不是 $font-size-base。
- 要用
as *才能让成员“升到顶层”：@forward "mixins" as *;，但强烈不建议——失去命名空间后，和@import的混乱没区别 -
@forward "file" show (func1, $var2)可以精确控制导出列表，隐藏内部实现细节 - 如果被
@forward的文件本身用了@use，它的依赖不会透出——@forward只转发自己@use或@forward的内容
迁移时最容易漏掉的三个硬伤
升级到 @use/@forward 不是全局替换字符串，Sass 编译器对路径解析、循环依赖、CSS 输出顺序都有更严的校验。
-
@use路径必须相对或带引号，@use src.variables错，@use "src/variables"对；Node Sass 不报错，Dart Sass 直接中断 - 循环
@use（A@useB，B 又@useA）在 Dart Sass 里是 fatal error，而@import时代可能只是样式错乱 - CSS @import 规则（
@import url("xxx.css")）和 Sass@import指令同名但语义完全不同，迁移到@use后，这类 CSS 导入必须保留原样，不能改成@use
真正的麻烦不在语法转换，而在团队协作时——有人忘了删旧的 @import，或者在 @use 文件里又写了 @import，Dart Sass 默认不警告，但输出结果可能缺失变量或混合宏，查起来像幽灵 bug。
