必须迁移到@use和@forward，因Dart Sass 3.0.0已移除@import；当前警告源于兼容模式下的全局污染、静默覆盖与冗余编译，@use需置于文件顶部并用命名空间访问变量，@forward用于封装透出接口。
直接改掉 @import，换成 @use 和 @forward，不是“可选优化”，而是必须做的编译器兼容动作——Dart Sass 3.0.0 已明确移除 @import，现在看到警告，说明你正站在编译失败的临界点上。
为什么 @import 报警告后还编译得过去？
因为当前用的是 Dart Sass 1.x 或 2.x 的兼容模式，它只是发警告，但仍在后台做“文本替换”：把被导入文件整个内容粘贴进当前文件，变量、mixin、CSS 规则全塞进全局作用域。这正是问题根源：
- 两个
_theme.scss和_vars.scss都定义了$spacing，后@import的会静默覆盖前一个，调试时根本看不出谁动的手 -
@import "mixins"在 5 个组件里各写一遍，编译器就解析 5 次_mixins.scss，生成冗余 CSS，热更新变慢 - Angular CLI 默认用 Dart Sass，升级到 v2.0+ 后警告频率升高，CI 环境若拉取最新 minor 版本，可能直接中断构建
@use 怎么写才不报错、不漏变量？
@use 必须出现在文件最顶部，且不能嵌套在 @media、@if 或选择器内部；路径不带扩展名和下划线，Sass 会自动找 _xxx.scss 或 xxx.scss：
- 基础写法：
@use "src/styles/variables" as v→ 访问变量必须写v.$primary-color - 省略
as时，默认命名空间是文件名（如@use "variables"→variables.$primary-color） - 禁止用
as *合并命名空间，否则variables.$radius和theme.$radius冲突时编译直接失败 - 如果某个文件只提供函数（如
_math.scss），用@use是唯一安全方式——@import会把它里面的空规则也输出成 CSS
@forward 不是 @use 的快捷方式，是封装接口
@forward 用在入口文件（如 index.scss 或 design-tokens.scss）里，目的是“透出能力，隐藏实现”。它不加载模块内容，只转发声明：
立即学习“前端免费学习笔记（深入）”；
- 透出并覆盖默认值：
@forward "variables" with ($spacing-unit: 4px)，下游@use "design-tokens" as t拿到的就是已覆盖的t.$spacing-unit - 隐藏不希望暴露的成员：
@forward "mixins" hide responsive-hover，调用方mixins.responsive-hover就会报错 - 重命名转发：
@forward "utils" as u-*，把所有成员加u-前缀，避免和业务层变量撞名 - 严禁循环：
A @forward B，同时B @forward A→ 编译报Circular @forward
Angular 项目迁移最容易卡住的三个点
Angular 的 styles.scss 通常是全局样式入口，也是 @import 最密集的地方。这里最容易翻车：
- 第三方库（如 Angular Material）仍用
@import？别硬改——保留其原始引入方式，用@use管理你自己写的模块，二者可共存（Dart Sass 兼容过渡期） - 组件级 SCSS 文件里还有
@import "../shared/mixins"？立刻替换成@use "@shared/mixins" as mixins，并确保tsconfig.json的paths配置已映射@shared/* - 用了
!default变量想被覆盖？旧写法$primary-color: red !default;+@import前赋值已失效；新写法必须靠@forward ... with ($primary-color: red)显式传入
真正难的不是语法转换，而是识别哪些变量/mixin 实际被跨模块共享、哪些只是历史遗留的“假公共”——这些地方一改，往往暴露出多年没发现的隐性依赖。
