@import因无作用域隔离被dart sass 1.70+标记为过时，导致变量覆盖、source map错乱、angular cli 17+构建失败；@use强制命名空间和模块化，@forward封装接口，但纯css/第三方库/动态路径仍需@import。
为什么@import会触发DEPRECATION WARNING甚至构建失败
因为 Dart Sass 自 1.70 起就把它当“过时语法”处理，不是建议改，而是机制上已不被信任——它不做作用域隔离，纯靠文本拼接，变量、@mixin、@function全扔进全局，后导入的同名定义无条件覆盖前面的，连警告都不报，只在运行时悄悄出错。
常见错误现象：Undefined variable "$color-primary" 看似没定义，其实是被另一个 @import 文件里的同名变量静默覆盖了；更糟的是 Chrome DevTools 的 source map 只指向最后那个定义位置，你根本查不到谁先写、谁后冲。
- Angular CLI 17+ 默认启用
strictSassImports: true，@import直接报错中断构建 - Vite 的 HMR 对
@import文件变更响应极差，改一个_mixins.scss可能触发整站 CSS 重编译 - 启用
--fatal-warnings（CI/CD 常见配置）后，@import不再是黄标警告，而是构建失败
@use 怎么强制你面对模块边界
@use 不是“换个写法”，它是硬性要求你声明依赖来源：默认用文件名作命名空间，@use "variables" 后必须写 variables.$primary-color，不能直接用 $primary-color。
路径规则很实在：_buttons.scss → 命名空间是 buttons；_utils.index.scss → 命名空间是 utils_index（点号自动转下划线）。
-
@use "variables" as v→ 引用写成v.$spacing-sm -
@use "variables" as *在 Dart Sass 5.0+ 是非法语法，别试 - 同一模块被 10 个文件
@use，Sass 内部只解析一次；而@import会重复解析 10 次
@forward 不是“高级 @import”，而是接口封装层
@forward 本身不引入内容，只把当前文件里 @use 的模块“转发出去”，让上级文件间接使用。它解决的是统一入口问题，比如设计系统里一个 _index.scss。
典型结构：_index.scss 里写 @forward 'colors'; @forward 'typography' with ($font-size-base: 1rem);，外部 @use 'index' as t 后就能用 t.$color-brand 和已覆盖的 t.$font-size-base。
-
@forward 'mixins' hide responsive-hover→ 下游调用mixins.responsive-hover直接报错 -
@forward 'utils' as u-*→ 所有成员加u-前缀，彻底规避命名冲突 -
@forward不支持with参数，配置必须在原始@use处完成
哪些地方还不能一刀切换
不是所有 @import 都能无脑替换成 @use，硬换反而引发新问题：
-
@import "normalize.css"这类纯 CSS 文件仍得用@import，@use不支持 - 第三方库（如 Bootstrap 4）没提供
_index.scss导出入口，@use "bootstrap"会失败，得等它升级或加 wrapper 层 -
@use不支持动态路径：@use "#{$theme}/vars"这种逻辑必须抽到 JS 构建层处理 - 混用
@import和@use时，@import仍会污染全局，导致变量意外覆盖——必须全量替换完才真正安全
真正的迁移难点不在语法替换，而在于理清哪些变量该导出、哪些该隐藏、命名空间怎么分层——一个没显式 @forward 的 $z-index-modal，可能让整个 UI 叠层失效，却不会报错，只在上线后闪现。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
