Live Sass Compiler 插件需手动配置settings.json并满足三个条件：确认sass命令可用、正确设置formats/generateMap/includeItems、排除BOM编码和多watch冲突。
Live Sass Compiler 插件本身不自动生效，必须手动配置 settings.json 并满足三个硬性条件，否则保存.scss文件完全没反应——这不是插件坏了，是它被 Sass 规范、编码或路径卡死了。
确认 sass 命令是否可用（90% 的失败源头）
Live Sass Compiler 虽然自带轻量引擎，但很多行为（比如 includeItems 扫描、部分 watch 逻辑）会 fallback 到系统 sass 命令。如果终端里 sass --version 报错，后续所有配置都白搭。
- 在 VSCode 终端（
Ctrl+`）中运行sass --version；若提示command not found，立刻执行npm install -g sass（别用node-sass，已废弃） - macOS/Linux 用户装完后需重启 VSCode，否则终端 PATH 不刷新；pnpm 用户还要检查
$HOME/.local/share/pnpm是否在$PATH中 - Windows 用户装完 npm 全局包后也建议重启 VSCode，确保继承最新 bin 路径
必须改的三项 liveSassCompile.settings 配置
插件默认把 .css 输出到和 .scss 同目录、不生成 .map、也不压缩——这直接导致 HTML 引不到文件、DevTools 点不到源行、调试全靠猜。
-
liveSassCompile.settings.formats：用数组定义输出规则，例如[{"format": "expanded", "extensionName": ".css", "savePath": "/css/"}]，表示所有编译结果存进项目根下的/css/目录 -
liveSassCompile.settings.generateMap：必须设为true，否则不生成.css.map，调试时看不到原始 SCSS 行号 -
liveSassCompile.settings.includeItems：必须显式加["**/_*.scss"]，否则所有下划线开头的文件（如_variables.scss）默认被跳过——这是 Sass 规范，不是插件 bug - 删掉
liveSassCompile.settings.savePath（如果误写了），它会覆盖formats里的savePath，造成路径冲突
保存不触发编译？盯住这三个静默失败点
状态栏没提示、控制台无报错、CSS 文件纹丝不动——大概率不是插件崩了，而是被以下三件事拦住了。
立即学习“前端免费学习笔记（深入）”；
- 右下角状态栏没显示你期望的工作区文件夹名？多文件夹工作区（Workspace）下，插件只监听第一个文件夹；关掉其他文件夹，只开当前项目根目录
- 右下角编码显示 “UTF-8 with BOM”？立刻点它 →
Save with Encoding→ 选UTF-8；BOM 头会让插件解析失败，静默退出 - 文件名以
_开头（如_mixins.scss）且没写进includeItems？Sass 规范强制跳过 partial 文件，不会报错，也不会编译
别让两个 sass --watch 进程同时写同一个 CSS 文件
如果你一边开着 Live Sass Compiler，一边又在终端手动跑 sass --watch src/scss/:dist/css/，两个进程可能同时写同一个 .css 文件——尤其 Windows 下容易写空、内容错乱、甚至文件锁死。
- 优先关掉终端里的
sass --watch，VSCode 插件响应更快、更稳定 - 如果必须共存（比如 CI 或构建流程需要），确保它们监听不同源目录或输出不同目标路径
- 注意
tasks.json里配的sass --watch和插件不能共享同一套输出路径，否则冲突不可避免
最常被忽略的是 BOM 编码和 includeItems 配置——它们不出错、不报红、不提示，只是安静地跳过文件。只要 SCSS 文件一动不动，先点右下角编码切 UTF-8，再检查 includeItems 有没有把 _ 开头的文件列进去。
