直接替换@import为@use必然报错，因二者非语法等价而是作用域模型重构：@use强制命名空间隔离，变量须显式前缀访问（如variables.$spacing-sm），路径需匹配下划线partial文件，且不支持css直引或隐式扩展。
直接替换 @import 为 @use 会大面积报错，这不是字符串替换就能解决的迁移，而是作用域模型的根本切换——旧写法依赖全局污染，新机制强制命名空间隔离。
变量访问失效：Undefined variable 错误怎么修？
这是迁移后最常遇到的现象。比如原 @import "variables" 后直接用 $spacing-sm，现在会报 Undefined variable。
-
@use默认创建以文件名（不含_和.scss）为前缀的命名空间，@use "variables"→ 必须写成variables.$spacing-sm - 用
as显式控制前缀更安全：@use "src/styles/vars" as v;→v.$font-size-base - 慎用
as *：它解构导入、放弃命名空间，仅适合单模块且需兼容旧代码的过渡期，但会重蹈@import的覆辙 - 第三方库如 Bootstrap 5.3+ 支持
@use，但函数调用必须带前缀：bs.str-to-num("12px")，不能直接写str-to-num("12px")
重复加载警告：Module was already loaded 怎么避免？
旧项目中多个文件都 @import "_mixins.scss" 是常态；迁移到 @use 后，同一模块被多次 @use 会触发该警告，但 Sass 内部已自动去重，不会重复编译。
- 警告本身可忽略，它只是提示“你写了多次，我们只处理一次”
- 真正要改的是调用逻辑：把共用模块统一
@use在入口文件（如main.scss），再通过@forward暴露给子模块，而非每个文件都独立@use - 如果子模块需要独立使用某工具函数，仍可
@use "tools" as t;，只要不冲突就无性能损失
循环依赖报错：Module cycle detected 如何破？
旧 @import 对循环依赖静默容忍，@use 则直接中断编译并报错，这是故意为之的健壮性增强。
- 典型场景：
colors.scss@use "generate"，而generate.scss又@use "colors" - 解法不是绕开，而是重构：提取共享逻辑到新文件（如
_utils.scss），让colors和generate都@use "_utils"，切断闭环 - Angular/Vue 单文件组件中的内联
@import（如<style lang="scss">@import "@/mixins";</style>）也必须手动改为@use，否则构建失败
Vite 或 Angular 构建工具报 legacy API 警告怎么办？
即使 SCSS 语法改了，构建工具若仍用旧版 Sass API，控制台仍会刷 warning。
- Vite 项目需在
vite.config.ts中显式启用现代编译器：preprocessorOptions: { scss: { api: 'modern-compiler' } } - Angular 项目需确认
angular.json中的"inlineStyleLanguage": "scss"且未覆盖sassOptions，否则可能 fallback 到旧模式 - 第三方库（如 Bootstrap 4）未适配
@use，只能保留@import；混用时注意顺序——@use模块不能依赖@import导入的变量，因为后者不在命名空间内
真正的难点不在语法转换，而在识别哪些变量本就不该被全局暴露——@use 不是新写法的包装纸，它是倒逼你重新设计样式模块边界的手术刀。一个 $primary-color 被五个文件直接修改的项目，迁完依然会出问题，只是错误从“颜色突变”变成了“编译失败”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
