先用atom --safe对比启动耗时，差值超800ms即可锁定插件拖慢；它绕过所有用户插件和config.cson，仅加载核心包，是判断瓶颈的黄金基准。
怎么用 atom --safe 快速锁定插件拖慢
不跑这步就调配置，等于蒙眼修车。atom --safe 是唯一能绕过所有用户插件和 config.cson 的隔离环境，它只加载 Atom 核心包，是判断性能瓶颈的黄金基准。
操作很简单：终端执行 atom --safe，等窗口完全起来后打开开发者工具（Ctrl+Shift+I），在 Console 里输入 atom.startupTime 查值；再退出、正常启动一次，同样查值。两者差值超过 800ms，基本可断定是插件问题。
-
atom --safe不读取~/.atom/config.cson，也不走任何插件开关逻辑，所以禁用插件后仍慢，就得怀疑 core 包或 Electron 层面的问题 - Windows 用户必须从 CMD/PowerShell 运行该命令，双击快捷方式无效
- macOS/Linux 若提示
command not found: atom，需先建软链：sudo ln -s /Applications/Atom.app/Contents/Resources/app/atom.sh /usr/local/bin/atom（路径按实际调整）
哪些插件最该优先禁用
不是“可能慢”，而是明确在大型项目或大文件场景下会同步扫描、递归匹配、生成 DOM 节点——属于高概率卡点。
-
file-icons：为每个文件路径调用fs.stat判断类型，项目含数千文件时 IO 压力陡增 -
tree-view：在项目含数千文件时会一次性渲染全部节点，CPU 占用常飙到 100% -
autocomplete-plus：默认对每个打开的文件做符号索引，若开启includeCompletionsFromAllBuffers，还会跨文件分析，内存爆炸风险极高
禁用顺序建议：file-icons → tree-view → autocomplete-plus；前两者禁用后常能立竿见影降 300–500ms。
为什么改 config.cson 比禁用插件更有效
插件禁用是“砍枝”，而改 config.cson 是“剪根”。尤其当项目固定、文件类型明确时，这几项调整收益远超逐个点 Disable。
- 在
"*"根节点下加：core.largeFileMode: true—— 强制启用大文件模式，哪怕文件只有 5MB，它跳过语法解析和大多数插件钩子 - 必须配：
core.useTreeSitterParsers: false—— Tree-sitter 在 >1MB 文件中极易栈溢出，关掉后可避免主线程冻结 - 若必须保留
tree-view，至少加：core.excludeVcsIgnoredPaths: true，但注意：它会让 Atom 反复扫描.gitignore，反而拖慢启动
控制台红字里找真凶，别信 incompatible-packages
incompatible-packages 工具只检查编译兼容性，对逻辑错误、API 调用失败、模块路径写错完全无感。它不报错 ≠ 插件没问题。
真正有用的线索藏在开发者工具里：Ctrl+Shift+I 打开 DevTools → Console 标签页 → 刷新 Atom → 找形如 Failed to activate package 'xxx' 或 Cannot find module 'yyy' 的报错。
- 常见原因：
package.json里"main"字段路径错误，或activationCommands触发条件永远不满足（比如设成"core:save"却从没保存过） - 用了 Electron 不支持的语法（如顶层
await、import.meta），require阶段直接抛错，根本走不到兼容性检查环节 - Mac 用户特别注意：从 Dock 点开 Atom 和从终端
atom命令启动，Node 环境变量可能不同，同一插件在两种方式下表现可能不一致
