Partial文件不会触发单独编译，因为Dart Sass默认仅将不以下划线_开头的.scss文件视为可编译入口；以_开头的文件（如_variables.scss）被编译器直接过滤，不参与构建扫描，仅在被@use显式引用时按需注入AST，零输出、零开销。
Partial 文件本身不参与独立编译，Sass 只处理被显式引用的入口文件，自然减少编译单元数量。
Partial 文件为什么不会触发单独编译
Sass 编译器（Dart Sass）默认只将**不以下划线 _ 开头**的 .scss 文件视作“可编译入口”。一旦你把 _variables.scss、_mixins.scss 这类文件名加上下划线，它就自动被排除在构建扫描范围之外——哪怕你把它放在 src/ 根目录下，Vite 或 Webpack 也不会为它生成对应的 CSS 输出，更不会启动一次独立编译流程。
常见错误现象：mixins.scss（没下划线）被误当成入口，结果构建工具多跑一次空编译，还可能因缺少顶层样式而报 Invalid CSS after ""；而 _mixins.scss 完全静默，只等被 @use 时才“按需注入”。
- 不是靠“文件小所以快”，而是靠“根本不编译”
- 构建工具通配符配置（如
"**/*.scss"）会匹配所有文件，但 Dart Sass 层面已过滤掉_开头的 - 没有
_前缀的 Partial 文件，会被当作无效入口：要么输出空 CSS，要么中断整个构建
@use 引入是静态分析 + 内联合并，不产生额外编译阶段
@use 不是运行时加载，也不是动态 import；它在 Sass 解析 AST 阶段就完成路径解析、作用域隔离和内容内联。整个过程发生在单次编译生命周期内，没有 I/O 轮询、无网络请求、不触发子进程。
对比旧式 @import（已被弃用）：虽然也是内联，但它不做作用域隔离，导致变量/Mixin 全局污染，迫使开发者手动加前缀或拆更细的文件来规避冲突——这反而增加文件数和维护成本，间接拖慢开发反馈速度。
-
@use 'colors'→ 找到_colors.scss→ 提取变量/混合宏 → 绑定命名空间 → 合并进当前 AST - 没有中间产物（比如临时 CSS 片段），不写磁盘，不跨进程
- 若某 Partial 未被任何
@use引用，它连 AST 都不会被加载，彻底零开销
真正影响编译速度的其实是“无效入口文件”和“循环依赖”
很多项目变慢，不是因为用了太多 Partial，而是因为：
- 忘了加
_前缀，导致几十个本该模块化的文件变成真实入口，每个都走一遍编译流水线 - 滥用
@import造成隐式全局合并，Sass 必须反复校验变量覆盖关系，尤其在大型设计系统中耗时明显 - 路径写错（比如
@use '../theme/dark'实际是../themes/_dark.scss），Sass 会遍历查找失败后才报错，白白消耗 CPU - 没配别名路径，满屏
../../../../styles/相对路径，不仅难读，还让构建工具的缓存失效更频繁
这些都不是 Partial 本身的锅，而是命名、引入方式和工程配置的问题。
真正要盯住的，是文件是否以 _ 开头、@use 是否写在顶部、路径是否匹配实际目录结构——其他都是表象。
