@import 因全局污染、无模块隔离、HMR差、官方弃用等问题被弃用；@use 通过命名空间、单次导入、配置传入和@forward转发等机制解决，但迁移需重构模块边界。
@import 在 Sass 中为什么越来越不推荐用
因为 @import 会全局污染变量、混合宏和函数，且无法控制导入内容的可见性。它本质是“文本拼接”，不是真正的模块系统。
常见错误现象：@import 同一个文件多次，导致变量重复定义报错；或后导入的 variables.scss 覆盖了前面已生效的值，但调用处却没反应——实际是作用域混乱导致的“看似没生效”。
- 所有被
@import的文件，其顶层变量、@mixin、@function全部注入到当前作用域，无隔离 - 不支持条件导入（比如只在开发环境导入调试样式）
- Webpack 或 Vite 等现代构建工具对
@import的 HMR（热更新）支持差，改一个变量可能触发整页重编译 - Sass 官方自 3.5 版起标记为 deprecated，v2.0+ 将彻底移除
@use 是怎么解决这些问题的
@use 是真正的模块导入机制：默认创建命名空间，变量/混合宏/函数必须显式加前缀访问，且只导入一次（即使多处 @use 同一文件）。
使用场景：组件库样式拆分、主题切换（不同 @use “theme-dark” 或 “theme-light”）、避免团队协作时样式名冲突。
立即学习“前端免费学习笔记（深入）”；
- 导入后默认使用文件名作为命名空间，如
@use 'base'→ 用base.$color-primary访问变量 - 可用
as重命名：@use 'base' as b→b.$color-primary - 用
with传入配置参数：@use 'button' with ($padding: 12px)，前提是button.scss内声明了$padding: null !default - 不支持循环依赖，Sass 会在编译时报
Circular @use dependency
@use 和 @forward 的配合逻辑
@forward 不是替代 @use，而是“转发模块”：把 A 文件中 @use 的 B 暴露给 C，让 C 间接使用 B，同时保持命名空间可控。
典型用途：设计统一入口文件（如 index.scss），聚合多个内部模块，对外只暴露精简 API。
-
@forward 'utils'：转发全部内容，但不带命名空间（C 文件仍需@use 'index'后用index.divider()） -
@forward 'utils' as utils-：添加前缀，C 中调用变成index.utils-divider() -
@forward 'utils' hide divider：隐藏某个成员，防止外部误用 - 转发不支持
with参数，配置必须在原始@use处完成
从 @import 迁移到 @use 的坑点
迁移不是全局替换字符串那么简单，最常卡在命名空间和默认导出行为上。
错误现象：@use 'vars' 后写 $color-text 报错 —— 因为 @use 默认不提升变量，必须写 vars.$color-text；而 @import 下直接可用。
- 不能混用：
@use和@import同在一个文件里，Sass 会拒绝编译 - 第三方库若仍用
@import（如旧版 Bootstrap），需等其发布@use友好版本，或用@forward封装一层 -
@use的路径解析更严格：相对路径以当前文件为基准，不支持@import那种模糊的“就近查找 node_modules”逻辑 - 想保留无前缀访问？只能用
@use 'xxx' as *，但这是反模式，仅限极小项目临时过渡
真正难的不是语法转换，是厘清哪些变量该暴露、哪些该封装、谁该负责配置——模块边界一旦划错，后面改起来比重写还费劲。
