正确做法是配置构建工具的 includePaths 或使用 --load-path 参数，而非手写绝对路径；新版推荐 @use 实现模块化导入，避免全局污染，但需注意兼容性与变量覆写方式。
怎么用 @import 正确引入 Sass 依赖包
直接在 .scss 文件里写 @import "node_modules/some-lib/scss/main" 多数时候会报错——Sass 默认不查 node_modules，它只认当前目录和你显式配置的 includePaths。
正确做法是配构建工具：Webpack 用 sass-loader 的 additionalData 或 includePaths；Vite 用 css.preprocessorOptions.sass.additionalData 或 includePaths；CLI 编译则加 --load-path=node_modules 参数。
- 别手写绝对路径，比如
@import "../../../node_modules/bootstrap/scss/functions"—— 路径一动就断 - 新版 Dart Sass 已弃用
@import，推荐改用@use，但很多老包（如 Bootstrap 4）还不支持@use，得降级或加兼容层 -
@use必须写在文件最顶部，且不能和@import混用在一个文件里，否则编译直接失败
@use 和 @import 在依赖管理上的关键区别
@use 是模块化导入：每个被 @use 的文件只执行一次，变量、函数、mixin 都带命名空间，避免全局污染；@import 是文本拼接，重复 @import 同一个文件会导致样式重复、变量覆盖、函数重定义。
比如你有两个组件都 @import "variables"，里面定义了 $primary: blue，第二个 @import 会把第一个的值冲掉；而 @use "variables" as v1 和 @use "variables" as v2 是完全隔离的。
立即学习“前端免费学习笔记（深入）”；
-
@use导入的成员默认私有，必须用public显式导出才能被外部访问 -
@import没有作用域概念，所有东西全扔进全局，容易和项目自有变量名冲突 - Bootstrap 5 开始全面支持
@use，但它的@forward用法很绕，比如要暴露内部模块得写@forward "functions" show function-name
如何让第三方 Sass 包适配项目主题变量
多数 UI 库（如 Bulma、Foundation）预留了可覆写的默认变量，但它们生效的前提是你在 @use 或 @import 之前就定义好自己的值。顺序错了就白搭。
例如 Bulma 要换主色，不能先 @use "bulma" 再设 $primary，得反过来：
$primary: #ff6b6b; @use "bulma";
- 有些包（如 Bootstrap）要求你
@import "functions"、@import "variables"、@import "mixins"分三步导入，中间插自己的变量定义，漏一步主题就不生效 - 用
@use时，变量覆写必须通过with关键字，比如@use "bulma" with ($primary: #ff6b6b)，不是直接赋值 - 注意变量类型是否匹配：
$body-color是颜色值，但如果你传字符串"#333"，某些版本 Sass 会静默失败而非报错
为什么 npm install 后 Sass 编译还是找不到包
常见现象是终端报错：Can't find stylesheet to import. 或 File to import not found or unreadable。根本原因不是没装包，而是构建链路没把 node_modules 告诉 Sass 解析器。
Webpack 用户最容易忽略 sass-loader 的 implementation 配置——如果用了 dart-sass 但没指定 implementation: require('sass')，loader 会 fallback 到 node-sass（已废弃），后者压根不支持现代 @use 语法。
- Vite 用户常卡在
vite.config.ts没配css.preprocessorOptions.sass.includePaths，尤其用 pnpm 时node_modules是硬链接，路径更敏感 - VS Code 的 Sass 插件（如 Ritwick Dey 的 Live Sass Compiler）默认不读构建配置，它自己搞一套路径规则，别指望它提示能跟实际编译一致
- 检查包里有没有
package.json的style或sass字段——没有的话，Sass 不知道该从哪开始找入口文件，得手动指定完整路径
真正麻烦的从来不是“怎么写”，而是“谁在什么时候、用什么上下文去解析那一行 @use”。不同工具链对 Sass 的封装程度差太多，同一份代码在 CLI 下跑通，在 Vite 里报错，在 Storybook 里又变样——得一个个环境单独对齐解析逻辑。
