sass文件名前加下划线是强制约定，用于标识局部文件（partial），防止被单独编译为css；\_开头仅限最前，@use引入时须省略下划线和扩展名，且路径全小写匹配。
为什么 Sass 文件名前面要加下划线
因为 _partial.scss 这种命名是 Sass 的“局部文件”（partial）约定，不是可选习惯，而是编译器识别机制。不加下划线的 button.scss 会被当作入口文件单独编译成 button.css，而 _button.scss 默认不会生成独立 CSS，只供 @use 或 @import 引入。
常见错误现象：_mixins.scss 改成 mixins.scss 后，构建工具突然多输出一个 mixins.css，且内容为空或报错 —— 这是因为它被当作了根文件，但里面只有 @mixin 没有顶层样式规则。
- 所有仅用于被引入、不含顶层样式的文件，必须以
_开头 - 文件名中下划线只能在最前面，
_btn-group.scss✅，btn_group.scss❌（会被编译），_btn_group.scss❌（Sass 不识别中间下划线为 partial） - Webpack / Vite 等现代构建工具仍遵循此规则；但某些老版 Ruby Sass 允许通过
--sourcemap参数绕过，不建议依赖
@use 和 @import 对下划线文件的处理差异
@use 是 Sass 5.0+ 推荐方式，它强制要求引入局部文件时**省略下划线和扩展名**；而 @import（已弃用）则允许带或不带下划线，容易引发歧义。
使用场景：你想复用一组颜色变量，放在 _colors.scss 中：
立即学习“前端免费学习笔记（深入）”；
// _colors.scss $primary: #007bff; $danger: #dc3545;
正确写法（@use）：@use 'colors'; —— 注意没写 _，也没写 .scss；错误写法：@use '_colors.scss'; 会报错 File not found。
-
@use 'colors'→ 找_colors.scss或colors.scss（优先前者） -
@use 'utils/helpers'→ 找utils/_helpers.scss -
@import 'colors'虽然也能工作，但会把_colors.scss中的变量全部注入全局作用域，造成污染，且无法启用命名空间控制
局部文件被意外编译的排查路径
如果你发现项目里出现了不该存在的 base.css、layout.css，大概率是某个 _base.scss 被构建工具误判为入口文件了。
关键检查点：
- 确认构建配置中是否把
src/scss/**/*\.scss这类通配符直接设为入口 —— 它会匹配到_base.scss，应改为src/scss/main.scss显式指定唯一入口 - Vite 用户注意：
vite-plugin-sass默认不会编译下划线文件，但如果在vite.config.ts中写了css.preprocessorOptions.sass.additionalData并拼接了 glob 导入，就可能触发 - VS Code 插件如 “Live Sass Compiler” 默认开启
compileOnSave，且对下划线文件无过滤，需在设置中关闭或加excludeList
跨平台协作时下划线命名的实际坑
Windows 文件系统不区分大小写，但部分 Git 配置或 CI 环境（如 macOS + case-sensitive filesystem）会对 _Button.scss 和 _button.scss 做不同处理，导致本地能跑、CI 报 No mixin named button-variant。
真正容易被忽略的是：Sass 的模块解析是**全小写路径匹配**，即使你写了 @use 'Components/Button'，它也会去找 _components/button.scss（取决于底层文件系统行为）。
- 统一团队使用小写字母 + 连字符命名：
_form-control.scss，而非_FormControl.scss - 避免在路径中混用大小写：
@use 'Layout/header'和@use 'layout/Header'在不同系统上可能指向不同文件 - CI 脚本里加一句
find src/scss -name "*[^a-z\-_].scss" -print可快速扫出违规命名
下划线本身不难，难的是它和路径解析、构建配置、团队习惯三者咬合时，错一点就全盘失效。
