--load-path解决SCSS编译器无法自动定位@use/@import目标文件的问题，通过显式指定搜索目录（如src/scss或node_modules），使@use "mixins"等简洁路径能准确命中src/scss/_mixins.scss或node_modules/bootstrap/scss/functions.scss，避免手写脆弱相对路径。
load-path参数到底解决什么问题
SCSS编译器默认只在当前文件所在目录及其子目录里找 @use 或 @import 的目标文件，遇到 node_modules 里的包、或者项目根下的 src/scss/_variables.scss，直接写路径会又长又脆——比如 @use "../../../src/scss/_variables"，一动文件位置就报 No module with the name。用 --load-path 就是告诉编译器：“这些目录你也可以放心进去翻”。
怎么配load-path才真正生效
关键不是“加了就行”，而是路径必须能和 @use 字符串拼出真实文件。比如你有文件 src/scss/_mixins.scss，想在 src/components/Button.scss 里写 @use "mixins"，就得让编译器知道 mixins 是指 src/scss/_mixins.scss。
- CLI 编译：加
--load-path=src/scss，然后@use "mixins"就能命中src/scss/_mixins.scss - Webpack + sass-loader：在
sass-loader的options里设includePaths: ['src/scss'] - Vite：在
vite.config.ts的css.preprocessorOptions.sass.includePaths加数组['src/scss'] - 别把
node_modules漏掉：要引用 Bootstrap 等包，得显式加--load-path=node_modules，否则@use "bootstrap/scss/functions"直接失败
@use路径写法必须匹配load-path规则
@use 后面的字符串不是“从哪开始找”，而是“在 load-path 列表里每个目录下拼这个路径”。所以它不支持模糊匹配，也不自动补 _ 或 .scss。
- 文件叫
src/scss/_colors.scss→ 必须写@use "colors"（不能写colors.scss或colors） - 路径含空格或中文 → Dart Sass 直接拒绝，
--load-path也救不了 - 多个 load-path 时，按数组顺序查找，第一个命中即停，不会合并结果
- 如果同时配了
--load-path=src/scss和--load-path=node_modules，@use "bootstrap/scss/functions"会去node_modules/bootstrap/scss/functions.scss找，而@use "colors"会去src/scss/_colors.scss找
为什么load-path + @use比手写相对路径更稳
手写 @use "../../theme/_typography" 看似直观，但只要文件挪个目录，所有引用全挂；而 --load-path=src/scss + @use "typography" 把路径逻辑收口到配置层，组件文件移动完全不影响样式引用。
立即学习“前端免费学习笔记（深入）”；
- 重构组件结构时，不用批量改 SCSS 路径
- 团队协作中，新人不用猜“这个
_utils到底在哪儿” - CI 构建时路径行为一致，不依赖开发者本地目录结构
- 注意：Dart Sass 是唯一支持
@use和--load-path组合的实现，Node Sass 已停更，别在旧工具链上硬套
最容易被忽略的是 load-path 的“作用域边界”：它只影响 @use 和 @import 的模块查找，对 url() 里的图片路径、CSS 中的 @font-face src 完全无效——那些还得靠 Webpack 的 file-loader 或 Vite 的别名配置来处理。
