sublime text 无法自动监测 sass 编译，需手动配置终端 sass --watch、sublime 构建系统及浏览器 livereload 三者协同；插件如 sassbuilder 已失效，推荐 sublimeonsavebuild + 自定义构建系统 + 终端独立监听。
Sublime Text 本身不提供自动监测编译能力，所谓 “SassBuilder” 并非官方或主流插件，也无稳定维护；你看到的“自动监测”实际是误用或混淆了构建系统、watch 进程和 LiveReload 的边界。真要实现可靠编译，必须拆解为三件事：终端跑 sass --watch、Sublime 正确调用 sass 命令、浏览器通知链路打通——缺一不可，且不能指望一个插件全包。
确认系统级 sass 命令可用，不是“装了就行”
npm 全局安装 sass（Dart Sass）只是第一步，Sublime 启动时根本看不到你的 shell PATH：
- macOS/Linux：在终端执行
which sass，拿到类似/opt/homebrew/bin/sass或/usr/local/bin/sass的绝对路径 - Windows：运行
where sass，常见结果是C:\Users\Alice\AppData\Roaming\npm\sass.cmd - 如果用了
nvm，确保当前 Node 版本下已执行nvm use 20 && npm install -g sass - 关掉 Sublime，**从 Dock / 开始菜单重新启动**——否则旧环境变量仍被缓存
别信“SassBuilder”类插件，用 SublimeOnSaveBuild + 自定义构建系统最稳
所谓 SassBuilder 插件早已停止更新，不支持 @use、@forward，报错静默，监听范围仅限当前 tab。推荐组合：
- 安装插件：
Ctrl+Shift+P→Package Control: Install Package→ 搜SublimeOnSaveBuild - 新建构建系统（
Tools → Build System → New Build System），贴入以下内容并保存为SCSS.sublime-build：
{
"cmd": ["sass", "--no-source-map", "$file", "${file_path}/${file_base_name}.css"],
"selector": "source.scss, source.sass",
"file_regex": "^(.*?):([0-9]+):([0-9]+) (.*)$"
}
-
--no-source-map必加，否则构建常卡住；需要 sourcemap 就换--embed-sources -
selector必须写成source.scss, source.sass，否则保存不触发 - 右下角状态栏必须显示
SCSS或Sass，否则构建系统完全不匹配
sass --watch 必须在终端独立运行，插件监听全是障眼法
所有声称“后台监听”的插件（包括 LiveSassCompiler）本质都是 fork 进程跑 sass --watch，但极易卡死、漏变更、不响应子目录修改。真实做法：
- 进项目根目录，执行：
sass --watch src/scss:dist/css（递归监听整个目录树） - 若只编译单入口，用：
sass --watch src/scss/main.scss:dist/css/main.css - 加
--style=compressed或--source-map直接控制输出，不用靠插件二次配置 - **绝不要把
--watch塞进 Sublime 构建系统里**——它会阻塞主进程，保存后卡顿几秒甚至假死
改了 _variables.scss 却没重编译？这不是 bug，是你没交出监听权
Sublime 插件（无论叫什么名字）都只监听当前激活 tab 的保存动作。你改了 _variables.scss，但没切回去保存 main.scss，CSS 就不会更新——这不是缺陷，是设计限制。
- 唯一能响应
@use/@import子文件变更的方式，就是终端里跑sass --watch - 它会自动追踪依赖图，
_variables.scss变了，所有引用它的文件都会重编译 - 插件里配的
output_dir、include_paths对--watch模式完全无效
真正容易被忽略的是：Sublime 启动方式决定它能不能看到 sass；而浏览器是否刷新，取决于你有没有手动加那段 <script></script> 并启用 LiveReload。这两处断了，再“自动”也是假象。
