@import被弃用因其导致变量静默覆盖、样式重复和调试失控；它本质是文件拼接，无命名空间，后导入同名变量无条件覆盖前者，而@use强制命名空间访问、避免污染，@forward用于安全透传模块接口。
@import 被弃用，不是因为它不能工作，而是它会让变量覆盖、样式重复、调试失控——尤其在中大型项目里，改一个颜色可能让三个不相关的组件变样。
为什么 @import 会静默覆盖变量
@import 的本质是文件内容拼接，所有被导入的变量、mixin、函数直接注入当前作用域。没有命名空间，没有加载控制，后出现的同名定义无条件覆盖前面的。
- 常见错误现象：
$primary-color在_colors.scss里是#007bff，在_theme.scss里又写了一次$primary-color: #28a745；@import 'colors'; @import 'theme';后，所有地方的$primary-color都变成红色系，但没人报错，也查不到来源 - 使用场景：多人协作的 Angular 或 Vue 项目，UI 库和业务样式共存时，第三方包里的
$spacing-sm和你自定义的同名变量极易冲突 - 根本原因：Sass 编译器不校验重名，也不记录变量“来自哪个文件”，Chrome DevTools 的 CSS 源码映射里只显示最终生效的那个位置
@use 怎么解决作用域污染
@use 强制模块化访问：每个文件默认私有作用域，变量必须通过命名空间显式调用，不再存在“全局泄漏”。
- 参数差异：
@use 'base/variables' as v;→ 必须写v.$primary-color；省略as v则默认用文件名（如variables.$primary-color） - 容易踩的坑：
@use 'utils' as *;是非法语法（Sass 5.0+ 明确禁止通配符导入），别试图用它模拟旧行为 - 性能影响：同一模块被多个文件
@use，Sass 内部只解析一次，编译速度明显快于反复@import - 注意兼容性：Angular CLI 17+ 默认启用 Dart Sass 2.x，若仍用 Node Sass 或旧版构建工具，
@use会直接报错Invalid CSS after "@use"
@forward 不是“高级 @import”，而是接口封装
@forward 不执行代码，只声明“我这个文件对外提供哪些东西”，适合做统一入口（比如 index.scss），把底层模块能力安全透传出去。
立即学习“前端免费学习笔记（深入）”；
- 常见错误现象：在
theme.scss里写@forward 'colors'; @forward 'typography';，然后期望用户@use 'theme'后能直接用$font-size-base—— 实际上仍需theme.$font-size-base，除非加as *（但不推荐） - 可控暴露：
@forward 'mixins' show hover-state, clearfix;可隐藏内部未设计好的@mixin transition-all，防止下游误用 - 路径管理：
@forward 'base/variables' as base-*;会让所有变量带前缀，比如base-primary-color，彻底规避命名冲突 - 不要混用：
@forward 'foo'; @use 'foo';在同一文件里会导致 Sass 警告"foo" has already been loaded，编译器会跳过第二次解析
真正难的不是语法替换，而是重构依赖流向：哪些该 @use（需隔离）、哪些该 @forward（需聚合）、哪些变量其实根本不该暴露——这些决策一旦定错，命名空间反而会让调用变得更啰嗦，而不是更清晰。
