atom beautify 默认不启用，需同时满足语言识别正确、cli 工具安装到位（用apm而非npm）、对应语言的beautify_on_save单独开启、文件编码为utf-8这五个条件才生效；右下角language-id错误（如plain text）或映射缺失（如.vue、dockerfile）会导致快捷键和右键菜单完全失效。
Atom 编辑器本身不带格式化能力，atom-beautify 插件装完默认“不干活”——它只在语言识别正确、CLI 工具就位、对应语言的 beautify_on_save 明确开启、文件编码为 UTF-8 这五个条件同时满足时，才真正执行美化。
右下角 language-id 不对，快捷键和右键菜单全失效
Atom 不靠文件后缀判断语言，而是依赖 grammar（即右下角显示的 language-id）。显示 Plain text、Source 或 Auto 时，atom-beautify 直接跳过，不报错也不响应。
- 手动点击右下角 language-id → 选
JavaScript、CSS、Vue Component等明确类型；.vue文件默认常被识别为HTML，导致<script></script>块不格式化，必须切到Vue Component -
.jsx、Dockerfile、.env等无标准后缀或冷门类型，需进Config → Core → File Types手动加映射，例如："Dockerfile": ["source.dockerfile"] - 快捷键
Ctrl+Alt+B或右键菜单无反应？先用Ctrl+Shift+P输入Change Language Mode切换一次再试
beautifier not found 报错，npm install 白装
atom-beautify 是调度器，不是格式化引擎。它运行时动态 require('js-beautify') 或 require('prettier')，但 Atom 的 Node.js 环境和你终端里的不是同一个，npm install -g js-beautify 基本无效。
- 统一用
apm install js-beautify（不是npm）——apm会把模块链入 Atom 运行环境 - 已装过仍报错？执行
apm rebuild，尤其在 Atom 升级或系统重装后 - Windows 用户若遇 PowerShell 执行策略拦截，临时运行：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser - C/C++、Python 等语言需额外装 CLI 工具：
uncrustify（C/C++）、autopep8或black（Python），并确保其可执行文件在系统PATH中
beautify_on_save 开了却没反应，不是全局开关
beautify_on_save 是按语言隔离的设置，不存在“一键全开”。JavaScript 开了，CSS 没勾，保存 .css 文件就完全静默。
- 路径：
Packages → atom-beautify → Settings→ 向下滚动找到具体语言区块（如JavaScript、CSS、HTML）→ 每个区块里单独勾选Beautify On Save - 默认开启
Ignore VCS Ignored Paths：如果文件在.gitignore里，保存时直接跳过格式化 -
debounce时间太短（默认 300ms）：快速连按Cmd+S只触发最后一次；可设为0测试是否是它导致漏触发 - 引擎冲突：若同时启用
prettier-atom，两个插件监听同一事件，结果互相覆盖甚至报错
配置文件优先级混乱，团队协作容易打架
.jsbeautifyrc 和 .prettierrc 会覆盖 UI 设置，但只覆盖明确声明的字段；未声明项仍回退到 UI 值。冲突最常发生在缩进、引号、分号等细节上。
-
.jsbeautifyrc必须是合法 JSON，字段名严格区分大小写：indent_size有效，indentSize被忽略 - 用了
prettier就建议项目根目录放.prettierrc；否则它用自身默认规则，容易和团队eslint风格冲突 -
.editorconfig会被读取，但只影响缩进、换行等基础项，不接管括号风格或空格逻辑 - 最容易被忽略的硬性前提：文件编码不是 UTF-8（比如 GBK）时，
atom-beautify会静默失败——不报错、不格式化
真正卡住人的地方，往往不在“怎么装”，而在“它认不认你当前这行代码”。语法识别错一位，后面所有设置都白配。
