差值超800ms即可锁定插件拖慢；先用atom --safe查startupTime，再正常启动对比，差值超800ms基本可断定是插件问题，此时应优先禁用autocomplete-plus、file-icons、tree-view，并修改config.cson启用largeFileMode、关闭useTreeSitterParsers。
用 atom --safe 对比启动耗时，差值超 800ms 就是插件问题
Atom 启动慢，八成不是 Electron 或系统问题，而是某个插件在后台同步扫描、递归匹配或生成 DOM 节点。关键第一步不是调配置，而是验证：终端执行 atom --safe，等窗口完全打开后，按 Ctrl+Shift+I 打开开发者工具，在 Console 里输入 atom.startupTime 查值；再退出、正常启动一次，同样查值。两者差值超过 800，基本可断定是插件拖慢。
注意：atom --safe 不读取 ~/.atom/config.cson，也不加载任何第三方包——它只是隔离环境，不是“简化版 Atom”。如果安全模式下也卡，问题可能出在 core 包、Electron 层或磁盘 IO 上。
优先禁用 autocomplete-plus、file-icons、tree-view
这三个不是“可能慢”，而是明确在大型项目或大文件场景下高概率卡点：
-
autocomplete-plus默认对每个打开的文件做符号索引；若开启includeCompletionsFromAllBuffers，还会跨文件分析，内存爆炸风险极高 -
file-icons为每个文件路径调用fs.stat判断类型，项目含数千文件时 IO 压力陡增 -
tree-view在项目含数千文件时会一次性渲染全部节点，CPU 占用常飙到 100%
禁用顺序建议：file-icons → tree-view → autocomplete-plus；前两者禁用后，常能立竿见影降 300–500ms。别只在 UI 点 Disable，要确保完全退出 Atom 后再重启生效。
改 config.cson 比禁用插件更治本
插件禁用是“砍枝”，而改配置是“剪根”。尤其当项目固定、文件类型明确时，这几项调整收益远超逐个开关：
- 在
"*"根节点下加：core.largeFileMode: true——强制启用大文件模式，哪怕文件只有5MB，它跳过语法解析和大多数插件钩子 - 必须配：
core.useTreeSitterParsers: false——Tree-sitter在 >1MB 文件中极易栈溢出，关掉后可避免主线程冻结 - 若必须保留
tree-view，至少加：core.excludeVcsIgnoredPaths: true；但注意，它会让 Atom 反复扫描.gitignore，反而拖慢启动
改完必须完全退出 Atom（macOS 在 Activity Monitor 结束所有 Atom Helper 进程；Windows 在任务管理器结束 atom.exe），否则新配置不加载。
别信“刚装完就卡”，有些插件的性能问题要等你打开第一个 JS 文件才暴露
像 linter-eslint、prettier-atom 这类插件，会在首次加载对应类型文件时才真正初始化 Node 子进程，这时才开始吃 CPU。所以安全模式下滚动大文件不卡，但正常模式一开 .js 就卡，说明问题不在编辑器底层，而在插件的实时监听行为上。
控制台红字里找真凶，别信 incompatible-packages 工具——它只检查编译兼容性，对逻辑错误、API 调用失败、模块路径写错完全无感。真正有用的线索藏在 DevTools → Console 里：Failed to activate package 'xxx' 或 Cannot find module 'yyy' 这类报错，才是定位真凶的关键。
