Sass --watch卡住主因是默认递归扫描node_modules和dist目录，且深层@use/@forward依赖解析耗时；应禁用source-map、显式指定路径、避免includePaths含node_modules根目录。
为什么sass --watch在项目变大后会卡住
因为默认的监听机制是递归扫描整个node_modules和dist目录，哪怕你只改了一个_mixins.scss，它也会重新遍历所有@import路径。尤其当项目里有深层嵌套的@use或@forward时，解析依赖图耗时明显上升。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
--no-source-map关闭源码映射（开发阶段非必需） - 显式指定输入/输出路径：
sass --watch src/scss/main.scss:dist/css/main.css，避免通配符扫描 - 把第三方 Sass 库（如
bootstrap/scss/）提前编译成 CSS 引入，别让sass每次重跑它们 - 检查
includePaths配置是否混入了node_modules根目录——这是最常被忽略的性能黑洞
Webpack + Sass Loader 怎么避开Invalid CSS after报错
这类错误通常不是语法写错，而是sass-loader版本和node-sass/sass（Dart Sass）不匹配导致的解析行为差异。比如node-sass@4.x不支持@use，但你用了，就会在renderSync阶段直接崩。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 统一用 Dart Sass：
npm uninstall node-sass && npm install sass - 在
webpack.config.js中确认sass-loader版本 ≥ 12.0（才完整支持@use和模块化路径解析） - 若用
@use "utils"，确保utils.scss文件名不带下划线（_utils.scss是私有文件，不能被@use直接引用） - 禁用
sourceMap选项时，sass-loader仍可能读取.map文件导致冲突——加sourceMap: false并清空dist再试
如何让sass --watch自动清理旧CSS文件
原生命令不清理，旧的main.css和main.css.map会一直残留，容易导致浏览器缓存旧样式、热更新失效或CI构建污染。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
npm-run-all组合命令："build:css": "sass src/scss/main.scss dist/css/main.css --no-source-map", "watch:css": "npm-run-all build:css --parallel 'sass --watch src/scss/main.scss:dist/css/main.css'" - 更稳妥的做法是加一层脚本封装，在每次编译前
rm -f dist/css/*.css*（Windows 用户用del /q dist\css\*.css*） - 如果用 VS Code，装
Live SASS Compiler插件时务必关掉liveSassCompile.settings.savePath的自动补全逻辑，它会在没改文件时也生成空.css
Dart Sass 的loadPaths和@use路径怎么对齐
loadPaths是编译器找文件的“搜索路径”，而@use里的字符串是“相对导入路径”，二者必须能拼出真实文件路径。常见坑是：设了loadPaths: ['src/scss']，却写@use 'base/variables'，结果找不到——因为实际路径是src/scss/base/_variables.scss，但@use会去找src/scss/base/variables.scss（缺下划线）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
@use只认_xxx.scss为模块文件，但写路径时不带_和.scss后缀；loadPaths指向的是目录，不是文件 - 推荐结构：
src/scss/index.scss（入口）→@use 'base/variables'→ 对应src/scss/base/_variables.scss - Webpack 中通过
sassOptions: { loadPaths: ['src/scss'] }传入，不要写成['src/scss/']（尾部斜杠会导致某些版本解析异常）
真正卡住人的从来不是语法，是loadPaths和@use之间那层薄薄的路径映射关系，以及不同工具链对“模块可见性”的隐含约定。多打一次ls -R src/scss比查三篇文档管用。
