@use是大型sass项目唯一可信赖的模块化入口，因其强制命名空间隔离、防变量冲突、只加载一次；@import本质是内容拼接，导致全局污染、重复编译、路径脆弱，已被sass官方废弃。
@use 是当前大型 Sass 项目唯一可信赖的模块化入口，不用它，变量冲突、样式重复、调试失焦会随项目增长指数级恶化。
为什么 @import 在大型项目里根本撑不住
它不是“导入”，是“内容拼接”——把 _variables.scss 的全部内容原样塞进当前文件，所有变量、@mixin 全局可见。结果就是：
- 两个模块都定义了
$spacing-sm，后@import的直接覆盖前一个，不报错、不提醒 -
@import "mixins/grid"出现在 5 个组件里，编译后 CSS 里就出现 5 份 grid 规则 - 路径全靠相对写法：
@import "../../theme/colors"，重构目录时批量炸掉 - Sass 官方自 1.30.0 起标记为
deprecated，Dart Sass 1.80+ 已彻底移除支持
@use 必须怎么写才真正起作用
它强制命名空间隔离，但写法稍有偏差就失效：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 必须放在文件最顶部，不能嵌套在
@media或选择器内部 - 路径不带扩展名和下划线：
@use "src/styles/vars"自动找_vars.scss - 默认命名空间 = 文件名（不含路径）：
@use "utils/breakpoints"→ 用breakpoints.max('md') - 重命名防冲突：
@use "components/button" as btn→btn.$primary-bg - 慎用
as *：只在极小模块（如纯工具函数库）中临时用，否则$radius来源无法追溯
@forward 是大型项目架构的骨架
单靠 @use 只能管“引入”，@forward 才能建“接口层”。没有它，每个组件都要重复 @use 十几个基础模块：
- 主入口
styles/index.scss应只写@forward "vars"、@forward "mixins" show hover-state, clearfix - 用
with提供可覆盖默认值：@forward "vars" with ($font-size-base: 16px) - 加前缀隐藏实现路径：
@forward "utils/breakpoints" as bp-*→ 外部调用bp-max('lg') - 禁止循环：
A @forward B后，B不能再@forward A，Sass 直接报Circular @forward
构建链路里最容易被忽略的兼容性点
语法对了，环境没配对，照样编译失败：
- Node Sass 已停更，必须用 Dart Sass：
npm install sass（不是node-sass） - Webpack 用户确认：
sass-loader ≥ 12.0+sass ≥ 1.33.0 - Vite 用户检查
vite-plugin-sass是否启用 Dart Sass 后端 - 别用
sass-resources-loader注入全局变量——它和@use的命名空间机制天然互斥，会绕过作用域控制
模块化不是加几个关键字的事，而是让每个变量、每个 mixin 都有明确归属和调用路径。一旦路径断了、命名空间乱了，大型项目里的样式问题就再难定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
