必须用@use替代@import并将样式输出收口到单一入口文件，否则依赖顺序、变量覆盖、重复编译和调试全失控；@use强制命名空间、禁止混用、只加载一次，真正实现可控依赖与显式拼接。
直接结论：大规模 Sass 项目必须用 @use 替代 @import，并把所有样式输出收口到单一入口文件；否则依赖顺序、变量覆盖、重复编译、调试断点全都会失控。
为什么 @import 在大项目里必然导致 CSS 顺序错乱
@import 不是“按你写的顺序拼文件”，而是触发依赖图解析——Sass 编译器会把所有被导入的 _variables.scss 提前合并进作用域，再重排样式规则。一旦多个组件都 @import "_mixins"，又各自定义了 $spacing，最终 CSS 里 .button 和 .card 的 margin 可能来自不同版本的变量，且位置随机。
- Webpack + css-loader 会进一步打散注入顺序，
@import "base.css"可能被当成独立模块异步加载 - 交叉引用（A
@importB，B@importA）不报错，但变量值不可预测 - 你看到的源码顺序 ≠ DevTools 里看到的 CSS 规则顺序，调试时根本找不到对应块
@use 怎么真正管住依赖链
@use 不拼接 CSS，只加载逻辑；它强制你把样式规则写在显式控制的位置，而不是靠导入顺序“碰运气”。
- 所有
@use必须放在文件最顶部，且不能和@import混用——编译器直接拒绝 - 变量、mixin 全部带命名空间：
vars.$color-primary，一眼看出来源，不会被其他模块冲掉 - 同一路径只能
@use一次，重复会报"vars" has already been loaded，杜绝隐式多次加载 - 第三方包（如 Bulma）必须用
@use "bulma" with ($primary: #ff6b6b)覆写变量，不是先赋值再@use
大型项目入口文件该怎么组织
入口文件（如 index.scss）不写任何实际样式规则，只做三件事：声明依赖、导出公共接口、手动拼接输出顺序。
- 只放
@use，不放@import；基础层（vars,mixins,layers）放最前，组件层（buttons,forms）放后 - 所有局部文件（
_buttons.scss等）只定义@mixin或%placeholder，不直接输出 CSS - 在入口里按需调用：
@include buttons.primary()或@extend %reset，顺序由你敲键盘决定 - 纯 CSS 文件（如重置样式
normalize.css）别@import，改用 Webpack 的asset/inline或 JS 里import "./normalize.css"
第三方 Sass 包（如 Bootstrap/Bulma）怎么安全接入
关键不是“能不能导入”，而是“谁控制变量生效时机”。老包不支持 @use？那就降级用 @import，但必须隔离在单独的 vendor 层，绝不和项目变量混写。
- 配构建工具
includePaths，比如 Vite 的css.preprocessorOptions.sass.includePaths = ["node_modules"]，别手写@import "node_modules/bulma/sass/utilities/_all" - Bootstrap 4 必须分三步：
@import "functions"→ 自定义变量 →@import "variables"→@import "mixins"，漏一步主题就失效 - Bootstrap 5 开始支持
@use，但要用@forward暴露内部模块，例如@forward "functions" show clamp - 所有第三方样式必须包裹在
@layer vendor里，自己业务样式用@layer app，避免靠!important覆盖
真正难的不是语法，而是把“谁定义变量”“谁消费变量”“谁输出 CSS”这三件事彻底分开——@use 强制你面对这个分离，而 @import 默默纵容混乱。一旦项目超过 10 个组件文件，没做这层切割，后面每加一个新模块，修复样式冲突的时间就会翻倍。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
