换上dart sass不会自动变快，因常见配置失误会使缓存失效：includepaths含node_modules、additionaldata中写@use、未显式设implementation、sourcemap开启、sass --watch监听范围过广等。
为什么用了 Dart Sass 还卡在编译环节
不是换上 sass 就自动变快——常见配置失误会让 Dart Sass 的缓存机制完全失效。比如 includePaths: ["node_modules"] 这种写法，会让编译器每次启动都递归扫描整个 node_modules 目录，I/O 开销远超语法解析本身。
- 检查
sass-loader配置里的additionalData：如果里面写了@use "variables"，每个.vue文件都会触发一次独立模块解析，@use的缓存价值归零 - 确认
webpack.config.js中是否显式设置了implementation: require("sass")；没设就可能 fallback 到残留的node-sass - 禁用
sourceMap（尤其 CI 环境）：生成 .map 文件可占总耗时 40% 以上
sass --watch 命令卡住的真实原因
sass --watch 默认行为是监听整个输入路径及其所有子目录，包括 node_modules 和 dist，哪怕你只改了一个 _mixins.scss，它也会重新遍历所有 @use 和 @forward 的依赖图。
- 用精确路径代替通配符：
sass --watch src/scss/main.scss:dist/css/main.css，不带**/*.scss - 加
--no-source-map参数，开发阶段非必需 - 第三方库（如
bootstrap/scss/）提前编译成 CSS 引入，别让它参与每次监听 - 删掉
includePaths里指向node_modules根目录的条目——这是最常被忽略的性能黑洞
@use 没提速？很可能是模块组织错了
@use 的缓存生效前提是“同一路径只解析一次”。但如果你把所有变量、混入、函数全塞进一个 tokens.scss，哪怕只改了 $font-size-base，整个模块缓存就失效；反过来，为每个变量单独建文件（_spacing-sm.scss、_spacing-md.scss），模块注册开销又会上升。
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
- 按功能粒度拆分：
@use "sass:math"、@use "utils/breakpoints" as bp、@use "tokens/colors" as c - 禁止
@use "variables" as *：破坏作用域隔离，编译器退化为全局查找模式 - 私有文件（
_mixins.scss）不能直接@use，要么重命名为mixins.scss，要么用@forward导出 - 避免在
vue.config.js的css.loaderOptions.sass.additionalData里写@use
CI 构建中 Sass 编译慢的根本症结
CI 环境里不该跑 --watch 或热更新逻辑，但很多人直接把开发脚本复制过去，导致构建卡在监听初始化或 source map 生成阶段。
- CI 脚本必须用静态编译命令，例如：
sass src/scss/main.scss dist/css/main.css --no-source-map - Webpack 项目中确保
sass-loader的sourceMap选项在 CI 下为false - 禁用所有调试输出：
--quiet或移除--trace、--verbose - 启用缓存：Dart Sass 1.32+ 支持模块级 AST 缓存，但需保证
node_modules不在监听路径内
真正拖慢编译的往往不是语法复杂度，而是配置里那些“看起来无害”的路径设置和 loader 链错配——尤其是 includePaths 和 additionalData 这两处，改完立刻见效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
