Sass项目应停用@import改用@use：因@import同步全局无作用域致冲突、重复编译；@use通过命名空间（如color.$primary）明确来源，需以_开头命名Partial，根文件统一@use，按职责边界组织层级，并用@forward精准透传变量混入。
为什么直接写 @import 会让 Sass 项目越来越难改
因为原生 @import 是同步、全局、无作用域的——每次引入都像把整个文件内容复制粘贴进当前上下文，变量/混入冲突、重复编译、调试时找不到样式来源，都是常态。尤其当 _variables.scss 被十个文件各自 @import，修改一个颜色可能在三个地方意外生效。
实操建议：
- 立即停用
@import（Sass 1.33+ 已弃用），改用@use -
@use默认启用命名空间，color.$primary这种写法能一眼锁定来源 - 所有 Partial 文件名必须以
_开头（如_mixins.scss），否则@use会报错“no module” - 只在根文件（如
main.scss）中@use，其他 Partial 之间不要互相@use，避免循环依赖
怎么组织 _base、_layout、_components 这类 Partial 目录
不是按“功能模块”粗暴切分，而是按「职责边界」和「复用粒度」来分：基础层只放不会变的底层规则，组件层只封装可独立使用的 UI 块，布局层管容器结构但不碰视觉细节。
常见错误现象：
-
_components/button.scss里写了margin-bottom: 1rem—— 这属于布局逻辑，应该交给父容器控制 -
_base/typography.scss直接定义h1 { font-size: 2rem; }—— 应该只提供$font-sizes变量和@mixin text-heading()，具体标签样式由_layout或_components调用 - 把响应式断点写死在每个 Partial 里 —— 统一收口到
_settings/breakpoints.scss，用@use "settings/breakpoints" as bp引入
@forward 和 @use 混用时，哪些东西会被“透传”出去
@forward 不是简单转发文件，它只转发你显式声明的部分：变量、混入、函数。没列出来的，下游就看不到。这能防止“污染命名空间”，但容易漏转关键项。
使用场景举例：想让 main.scss 一行代码加载整套基础配置：
@forward "settings/colors" show $primary, $secondary; @forward "tools/mixins" show clearfix, ellipsis;
注意点：
-
show后面必须是具体名称，不能写show *（语法错误） - 如果
_colors.scss里定义了$accent但没在@forward中列出，main.scss就访问不到它 - 多个
@forward转发同名变量（比如都转$spacing），会触发编译错误：“name is already used”
开发时热重载失效或样式丢失，先查哪几个地方
90% 的热重载问题跟 Partial 的引用链断裂有关，而不是 Webpack 或 Vite 配置。
排查顺序：
- 检查终端报错里是否出现
Can't find stylesheet to import—— 多半是路径写错，@use "base/variables"实际文件是_variables.scss，但路径少写了base/或拼错大小写 - 打开浏览器开发者工具，看
Computed面板里某条样式对应的 source 是main.css:123还是_buttons.scss:45—— 如果全是main.css，说明@use没生效，回退到了旧的@import行为 - 运行
sass --watch src/main.scss:dist/main.css --trace，看编译日志里有没有跳过某些 Partial（比如因语法错误被静默忽略） - 确认构建工具插件版本：sass-loader ≥ 13、vite-plugin-sass ≥ 2.3，老版本对
@use支持不全
Partial 结构本身不增加运行时开销，但层级太深（比如 @use "a" then a uses "b" then b uses "c"）会让编译变慢，超过 5 层嵌套就得考虑合并或重构。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
