关键不是语法替换，而是模块边界和调用链控制；@use默认私有导出，需显式@forward或命名空间访问才暴露，配合构建工具配置manualChunks或splitChunks才能实现CSS按需分割与首屏体积降低。
直接改用 @use + 按需 @include，配合构建工具的 CSS 代码分割，才能真正降低首屏样式体积。纯靠压缩或合并文件，对大型 SPA 几乎无效。
为什么 @import 是大型 SPA 的样式加载瓶颈
它不是“慢一点”，而是让构建器无法做任何静态分析：每次编译都必须递归展开所有 @import 文件，哪怕某个组件只用了一个变量，整个 _variables.scss 和它依赖的全部 mixins 都会被无差别注入到每个输出 CSS 中。
- Webpack/Vite 对
@import不做 tree-shaking，button.scss和modal.scss各自@import "mixins"，最终打包里就有两份相同的 flex 工具类 - 路径别名（如
@import "@/styles/vars"）在旧版 sass-loader 中不解析，实际走的是 node_modules 查找逻辑，容易误引第三方库的同名文件 -
@import "base/reset"这类全局重置样式，一旦被任意一个组件引入，就会污染所有 chunk 的 CSS 输出，导致提取公共样式失败
@use 怎么写才真正减少 CSS 体积
关键不是语法替换，而是模块边界和调用链控制。Dart Sass 的 @use 默认私有导出，只有显式 @forward 或命名空间访问才暴露，这为按需提取打下基础。
- 把通用工具抽成独立文件，例如
utils/_flex.scss，只@forward "flex-center"，不@forward "all" - 组件级样式文件（如
components/Button.scss）必须@use "utils/flex" as flex，然后@include flex.center()，禁止@use "utils" as * - 入口文件（
main.scss）里只@use "theme/colors" as colors，再通过:root注入 CSS 变量，而非直接生成一堆.btn-primary { color: #007bff; } - 避免
@use "sass:math"在样式文件里做计算——这类函数应在构建时执行，不要拖到浏览器运行时；数值运算尽量提前算好，写死在变量里
Vite/webpack 中 CSS chunk 分割的实际配置点
光写对 Sass 语法没用，构建工具必须识别并拆分。默认配置下，所有 SCSS 最终都会打进一个 style.css，跟没用 @use 一样。
立即学习“前端免费学习笔记（深入）”；
- Vite 用户：在
vite.config.ts的build.rollupOptions.output.manualChunks中，按路径匹配 SCSS 引入关系，例如/node_modules\/bootstrap\/scss\//单独切出vendor.css - Webpack 用户：启用
mini-css-extract-plugin的splitChunks.cacheGroups，但注意要配enforce: true和test: /\.(scss|sass)$/，否则只切 JS 不切 CSS - 禁用
sass-loader的additionalData全局注入——它会把所有变量塞进每个模块开头，彻底破坏 chunk 边界；改用@use显式导入 - 检查生成的
.css文件是否含重复选择器：如果Button.css和Card.css都含.sr-only，说明@use "utils/a11y"没做正确隔离，应改用 CSS 自定义属性替代
真正卡住加载效率的，往往不是某行 Sass 写得不够优雅，而是变量和 mixin 的作用域泄漏让构建工具失去优化依据。一旦 @use 路径写错、命名空间漏掉、或在 partial 里用了 as *，就等于关掉了所有 CSS 分割的可能。
