直接删_unused.scss不一定生效，因@import/@use会递归解析依赖链，构建工具可能自动扫描所有.scss文件；真正排除需切断符号引用，用@use命名空间隔离、@forward hide屏蔽成员，并约束构建入口点。
为什么直接删 _unused.scss 文件不一定生效
因为 Sass 的 @import 或 @use 会递归解析依赖链，哪怕你手动删了某个 partial，只要它被其他文件通过路径引用（比如 @use "components/unused"），编译时仍会报错或意外加载。更隐蔽的是：某些构建工具（如 Vite 的旧版插件）会扫描整个 src/**/*.scss 并自动注入，根本不管你有没有显式引用。
@use 和 @forward 控制模块可见性才是真排除
真正“排除”不是靠文件系统删除，而是切断编译时的符号引用。Sass 模块系统提供了精确控制能力：
-
@use "utils/helpers" as helpers→ 只暴露helpers.$var、helpers.text-truncate()，其他全隐藏 -
@forward "base/mixins" hide clearfix, reset→ 主动屏蔽特定成员，下游无法访问 -
@use "legacy/theme" as legacy后不调用任何legacy.*→ 该模块代码不会进入输出 CSS（Dart Sass ≥1.23.0 会做 tree-shaking）
Webpack/Vite 中防止误扫未引用文件
构建工具常默认监听所有 .scss 文件，导致未引用的 _debug.scss 或 _old-layout.scss 被当作入口编译。必须显式约束入口点：
- Webpack：
css.loaderOptions.sass.additionalData不要设全局注入；入口 JS 中只import './main.scss'，别用require.context扫目录 - Vite：
css.preprocessorOptions.sass.additionalData清空；检查是否有插件（如vite-plugin-sass-glob-import）在后台自动@import所有文件 - 命令行编译：
sass src/main.scss dist/main.css—— 只传明确入口，别用sass src/**/*.scss
如何确认某段样式真的没进最终 CSS
不能只看文件是否存在，得验证输出结果：
立即学习“前端免费学习笔记（深入）”；
- 搜索最终
dist/main.css中是否存在关键选择器，比如.legacy-header - 用
grep -n "\.legacy-header" dist/main.css确认是否零匹配 - 若用了 PurgeCSS，检查它的
purgecss --rejected输出，看该类是否列在被删列表里 - 注意：如果该类名出现在 JS 字符串中（如
className="legacy-header"），PurgeCSS 可能保留它——这说明“排除”失败点其实在 content 配置漏了模板路径
