先用atom --safe对比启动耗时，差值超800ms即可锁定插件拖慢；优先禁用autocomplete-plus、file-icons、tree-view；再通过config.cson强制启用largeFileMode并关闭useTreeSitterParsers。
插件加载慢，先用 atom --safe 对比启动耗时；差值超 800ms 就能锁定是插件拖慢——没跑过这步就调配置，等于蒙眼修车。
怎么快速定位哪个插件在拖慢启动
安全模式绕过所有用户插件和配置，只加载 Atom 核心包，是判断瓶颈的黄金基准。终端执行 atom --safe，等窗口完全起来后打开开发者工具（Ctrl+Shift+I），输入 atom.startupTime 查值；再退出、正常启动一次，同样查值。两者差值超过 800ms，基本可断定是插件问题。
注意：atom --safe 不读取你的 config.cson，也不走任何插件开关逻辑，所以禁用插件后仍慢，就得怀疑 core 包或 Electron 层面的问题。
- 如果
atom --safe下滚动大文件不卡，但正常模式卡，说明问题不在编辑器底层，而在某几个插件的实时监听行为上 - 某些插件（如
linter-eslint、prettier-atom）会在首次加载文件时才真正初始化 Node 子进程，这时才开始吃 CPU - 别信“刚装完就卡”——有些插件的性能问题要等你打开第一个 JS 文件才会暴露
哪些插件最该优先禁用
autocomplete-plus、file-icons、tree-view 这三个不是“可能慢”，而是明确在大型项目或大文件场景下会同步扫描、递归匹配、生成 DOM 节点，属于高概率卡点。
-
autocomplete-plus默认对每个打开的文件做符号索引，若开启includeCompletionsFromAllBuffers，还会跨文件分析，内存爆炸风险极高 -
file-icons为每个文件路径调用fs.stat判断类型，项目含数千文件时 IO 压力陡增 -
tree-view在项目含数千文件时会一次性渲染全部节点，CPU 占用常飙到 100% - 禁用顺序建议：
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，避免递归扫描node_modules或.git - 别加
excludeVcsIgnoredPaths: true就以为万事大吉——它会让 Atom 反复扫描.gitignore，反而拖慢启动
插件装了但不生效？大概率是 Node 版本不匹配
插件显示“已启用”，但快捷键没反应、语法高亮不生效、面板打不开，不是安装失败，而是 Atom 内置 Node 运行时不认模块。Atom 自带独立 Node（当前主流版本为 v12.x 或 v14.x），不走系统 Node。
- 检查方式：打开 Atom DevTools，输入
process.versions.node - 若插件含原生模块（如
spell-check、term3），必须重编译：apm rebuild（不是npm rebuild） -
apm rebuild报zlib错误？说明缓存已损坏，先跑apm clean再重来 - 彻底卡死时，用
git clone + npm install手动兜底——尤其适用于只在 GitHub 发布、不在官方仓库的插件
复杂点在于：很多卡顿不是单点问题，而是多个插件叠加触发的连锁反应；容易被忽略的是，apm rebuild 必须在完全退出 Atom（包括后台进程）后执行，否则无效。
