atom-build-sass和less-build是最稳组合，二者不带编译器仅调用全局sass/lessc命令，需先npm install -g sass less并配置executablePath；配合build-on-save实现保存自动编译，注意路径无空格中文、语法标识为source.scss。
atom-build-sass 和 less-build 是当前最稳的组合
这两个插件不带编译器，只负责调用系统已安装的 sass 或 lessc 命令，所以兼容性好、更新及时、出问题容易定位。它们不依赖 Atom 内置终端环境变量，适合 macOS（zsh + Homebrew）、Windows（PowerShell）和 Linux 多种配置。
常见错误现象：Build failed: Command not found: sass 或保存后无反应——本质是插件找不到全局命令，不是插件本身坏了。
- 必须先在终端运行
npm install -g sass less（Dart Sass + official less），别装node-sass（已废弃） - 验证是否装对：运行
sass --version，输出应含Dart Sass字样 - macOS 用户若
which sass返回路径如/opt/homebrew/bin/sass，需在插件设置里填进executablePath - Windows 用户注意：Node.js 安装时勾选「Add to PATH」，否则全局命令可能仅在 PowerShell 里有效，Atom 却读不到
想保存即编译？build-on-save 必须配对启用
Atom 默认不监听文件保存事件触发构建，atom-build-sass 单独装完只是让你能按 Ctrl+Alt+B 手动编译。要实现改完 _variables.scss 就立刻生成 style.css，得加装 build-on-save 插件。
使用场景：团队协作中频繁改样式变量、调试响应式断点、快速验证嵌套结构输出。
-
build-on-save启用后默认对所有支持构建的文件类型生效，但可能被file-types类插件屏蔽（比如把.scss错误映射成source.css） - 检查方式：右下角状态栏点击语法标识（如 “SCSS”），确认显示的是
source.scss，不是source.css - 如果保存没反应，先关掉其他 lint 或 auto-format 插件临时排查，避免冲突
sass-autocompile 插件慎用：watch 模式易卡住
它自带 --watch 能力，看似省事，但实际在 Atom 中常因路径解析异常或子进程未清理导致构建卡死、CPU 占满、热重载失效。尤其当项目含大量 @import partials 或用了 @use + index 规范时更明显。
性能影响：启动时会扫描整个 styles/ 目录树，比 atom-build-sass + build-on-save 组合多开一个长期运行的 Node 子进程。
- 只建议用于小型单页项目，且明确关闭了
build-on-save等同类插件 - 配置项里
outputPath必须写相对路径（如../css/style.css），绝对路径会导致 watch 失效 - 若遇到“编译完成但 CSS 未更新”，先查
console.log输出里有没有File changed, recompiling...，没有就说明 watch 根本没挂上
别碰 language-sass、atom-sass 这类过时插件
language-sass 只提供语法高亮和缩进，atom-sass 依赖早已停更的 Ruby Sass，二者都不参与编译流程。装了反而可能干扰 atom-build-sass 的语法识别，导致变量名、mixin 调用无法被正确解析。
容易踩的坑：在插件市场搜 “sass” 时，前几条常是这些老插件，图标陈旧、最近更新时间停留在 2019 年前。
- 确认插件维护状态：点进详情页看 GitHub 仓库是否有 2025 年后的 commit，issue 是否有响应
- 真正需要的只有三样：
atom-build-sass（或less-build）、build-on-save、linter-scss-lint（可选，做语法校验） - 如果项目同时用 Sass 和 Less，不要混用插件配置——
atom-build-sass对.less文件完全无响应，得靠less-build单独配一套
C:\Users\张三\Desktop\my-project 这种路径下，sass CLI 会直接拒绝编译，报错却不提示原因。 
