live sass compiler 不编译是因未同时满足三条件：文件名不以下划线开头、项目根目录已打开、编码为utf-8（无bom）；否则静默跳过，需在includeitems中显式添加partial文件。
监听编译不更新，大概率不是 Sass 崩了，而是它压根没“看到”你改了什么——路径、文件名、编码或进程冲突中的任意一个出问题，都会导致静默跳过。
Live Sass Compiler 插件不编译的三个硬性条件
这个插件不会报错，只会默默忽略。必须同时满足：
- 文件名不以下划线开头（
_mixins.scss被视为私有 partial，直接跳过） - VSCode 左下角显示的是项目根目录（多文件夹工作区只监控第一个）
- 文件编码是 UTF-8，不是 UTF-8 with BOM（右下角点编码 → “Save with Encoding” → 选纯 UTF-8）
如果改了 _layout.scss 没反应，不是插件坏了，是它本就不该编译。得在 liveSassCompile.settings.includeItems 里显式加进去，比如：["**/_layout.scss"]。
sass --watch 同时跑多个进程会抢写 CSS 文件
Windows 下尤其明显：一个进程刚写完 main.css，另一个立刻覆盖，结果浏览器加载到一半的样式，热更新失效，甚至卡死。
- 关掉 Live Sass Compiler 插件，再手动跑
sass --watch；或者反过来，别手动起命令 - 检查任务管理器或终端，确认没有残留的
sass进程（ps aux | grep sass或 Windows 的任务管理器） - 输出路径别重叠：两个命令都往
dist/css/main.css写，必然冲突
@use 导入的文件修改后不触发重新编译
不是缓存太强，是 Dart Sass 根本没把那个文件纳入监听图谱——常见于路径写法不规范或 includePaths 配置错误。
-
@use "bootstrap/scss/functions"这种写法默认失败，因为没告诉 Sass 去哪找bootstrap目录；必须配includePaths: ["node_modules"]，但注意：不能写成["node_modules"]，否则每次启动都递归扫描整个node_modules，I/O 卡住，监听根本起不来 - 正确做法是精确指向：
["node_modules/bootstrap/scss"] - 第三方库（如 Bootstrap）建议提前编译成纯 CSS 引入，别让它参与每次监听
行尾符和路径分隔符引发的解析差异
你在 Windows 上保存的 .scss 文件若用 CRLF 换行，Dart Sass 解析变量或 map 时可能截断值；而 @import "./components/button.scss" 在 Windows 终端里若被误读为转义序列，也会静默失败。
- 所有路径统一用正斜杠：
@use "./tokens/colors" as c，别用反斜杠 - 编辑器设为 LF 换行（VSCode 右下角换行符切换）
- 避免动态拼接路径：
path.join(__dirname, 'styles')生成的字符串可能含反斜杠，传给 Sass 前先.replace(/\/g, '/')
真正难排查的，往往是某处 includePaths 里混进了 node_modules 根目录，或者某个 @use 路径看似正确，实则因大小写或 CRLF 被解析器判定为“新模块”，缓存失效又不报错。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
