先用 atom --safe 对比启动耗时，差值超800ms可锁定插件拖慢；优先禁用 autocomplete-plus、file-icons、tree-view；配合 config.cson 调整 core.largeFileMode、useTreeSitterParsers 等关键项。
插件加载慢，先看是不是被 atom --safe 拉出来对比过
没跑过 atom --safe 就直接调配置，等于蒙眼修车。安全模式下只加载核心包，不走任何第三方插件逻辑，是判断性能瓶颈的黄金基准。
操作很简单：终端执行 atom --safe，等窗口完全起来后，用 atom.startupTime 查启动耗时；再关掉、正常启动一次，同样查值。如果差值超过 800ms，基本能锁定是插件拖慢的。
- 别信“刚装完就卡”——有些插件（比如
linter-eslint、prettier-atom）会在首次加载文件时才真正初始化 Node 子进程，这时才开始吃 CPU -
atom --safe下滚动大文件不卡，但正常模式卡，说明问题不在编辑器底层，而在某几个插件的实时监听行为上 - 注意：安全模式不会读取你的
config.cson里插件开关状态，它绕过所有用户配置，所以禁用插件后仍慢，就得怀疑 core 包或 Electron 层面的问题
哪些插件最该优先禁用？盯住 autocomplete-plus、file-icons、tree-view
这三个不是“可能慢”，而是明确在大型项目或大文件场景下会同步扫描、递归匹配、生成 DOM 节点，属于高概率卡点。
autocomplete-plus 默认对每个打开的文件做符号索引，file-icons 为每个文件路径调用 fs.stat 判断类型，tree-view 在项目含数千文件时会一次性渲染全部节点——三者叠加，Atom 启动时 CPU 占用常飙到 100%。
- 禁用顺序建议：
file-icons→tree-view→autocomplete-plus；前两者禁用后常能立竿见影降 300–500ms - 如果必须保留
tree-view，至少在config.cson中加core.excludeVcsIgnoredPaths: true，避免扫描node_modules或.git目录 -
autocomplete-plus可以保留，但务必关掉useCoreProvider和includeCompletionsFromAllBuffers，否则它会跨文件分析，内存爆炸风险极高
config.cson 里这几个键值，比插件开关还管用
插件禁用是“砍枝”，而改 config.cson 是“剪根”。尤其当项目固定、文件类型明确时，这几项调整收益远超逐个点 Disable。
重点不是全写进 "*" 根节点，而是按需分层配置。例如只对 Go 项目生效，就写在 "source.go" 下；只对日志类文件生效，就写在 "text.plain" 下。
-
core.largeFileMode: true：强制启用大文件模式，哪怕文件只有 5MB —— 它跳过语法解析和大多数插件钩子，是最快见效的开关 -
core.useTreeSitterParsers: false：Tree-sitter 解析器在 >1MB 文件中极易栈溢出，关掉后回退到 TextMate，稳定性和速度都更好 -
editor.softWrap: false和editor.showInvisibles: false：这两项关闭后，每行渲染成本下降约 40%，对长行日志或 minified JS 特别有效 -
core.deferredLoadTime: 1200：延迟加载非核心插件 1.2 秒，让界面先出来，再后台激活补全、格式化等功能
别忽略 init.coffee 里的隐形负载
很多人以为插件开关和 config 就够了，但 init.coffee 里几行看似无害的 require 或 atom.packages.onDidLoadInitialPackages 回调，可能正在同步加载模块、初始化服务。
典型陷阱是：在 init 脚本里调用 atom.packages.activatePackage('some-plugin')，或者用 setTimeout 延迟加载却没设 clearTimeout，导致多个定时器堆积。
- 检查
init.coffee是否包含require非 Atom 自带模块（如fs-extra、glob），这些同步 I/O 会阻塞主线程 - 所有
setTimeout必须配clearTimeout，否则每次重启 Atom 都新增一个计时器，越用越慢 - 如果用了
atom.packages.onDidLoadInitialPackages，确保回调函数里没有await或长时间运行的循环，它本身就在主线程执行
真正难搞的从来不是某个插件，而是多个轻量级插件在启动链路上叠加的微小延迟——它们单个只拖慢 50ms，但 10 个一起就是半秒。优化得从测量开始，而不是凭感觉删。
