必须强制启用largeFileMode并禁用Tree-sitter：在~/.atom/config.cson的core下添加largeFileMode: true和useTreeSitterParsers: false，完全退出Atom后重开才生效；Tree-sitter会导致内存暴涨和主线程阻塞，禁用后回退TextMate高亮对日志/JSON影响极小。
Atom 打开大文件卡，核心原因不是“文件太大”，而是它默认还在用 IDE 级别的解析和渲染逻辑去处理日志、dump、CSV 这类只读场景——必须强制切到轻量模式，否则再强的 CPU 也扛不住。
如何强制启用 largeFileMode 并禁用 Tree-sitter
Atom 默认对 >2MB 文件可能自动触发 largeFileMode，但不可靠；尤其遇到无换行符、二进制头或语法解析器报错时，根本不会进该模式。真正起效的方式是手动覆盖：
- 编辑
~/.atom/config.cson（Windows 是%USERPROFILE%\.atom\config.cson） - 在
core:下添加两行：largeFileMode: true useTreeSitterParsers: false
- 必须完全退出 Atom（不是刷新或关闭窗口），再重新打开文件才生效
-
useTreeSitterParsers: false很关键：Tree-sitter 在大文件中会持续构建语法树，内存暴涨且阻塞主线程；关掉后回退到 TextMate 高亮，对纯文本/日志/JSON 影响极小
为什么关插件比调参数更立竿见影
插件才是大文件卡顿的第一推手，不是“有点慢”，而是“一开就冻结”。典型现象包括：
- 打开 50MB 日志后，
atom.exe或Atom Helper占满 CPU，界面无响应 - 滚动几屏后卡死，开发者工具里
TextEditorComponent.render耗时超 800ms - 保存失败，控制台报
RangeError: Maximum call stack size exceeded（来自高亮递归） - 运行
apm list --installed，重点清理：linter-eslint、atom-ide-ui、minimap、highlight-line - 临时验证是否插件导致：终端执行
atom --safe /path/to/big.log，如果流畅，就坐实了插件问题
必须关闭的编辑器渲染选项
Atom 默认仍为每行生成完整 DOM 节点，大文件下直接内存溢出。以下配置加到 config.cson 的 editor: 下即可生效：
-
softWrap: false—— 软换行会强制重排整段，大文件下必卡 -
showInvisibles: false—— 不显示空格/制表符，省掉大量 SVG 渲染 -
scrollPastEnd: false—— 避免底部留白区域触发额外布局计算 -
scrollSensitivity: 40—— 默认是 30，调高一点可减少触控板微动引发的高频重绘 - 绝对不要碰
chunkSize等底层参数：它藏在src/text-editor.js里，改错会导致崩溃，官方未开放配置入口
绕过 UI 层：用命令行 + 基础模式预处理
图形界面本身就有渲染开销，对只读查看场景，没必要加载整个 UI 栈：
- 用
head -n 1000 huge.json | atom -替代双击打开全量文件 - 对 CSV 或日志，先用
awk、grep或jq过滤关键字段再进 Atom - 若必须保留
file-icons，务必进其设置页勾选Enable icon caching，否则每次展开目录都会正则匹配全路径，性能雪崩 - 不要依赖
minimap：它会为整份文件生成 Canvas 缩略图，100MB 文件大概率 OOM
最易被忽略的一点：即使开了 largeFileMode: true，如果语法包本身还在做深度解析（比如 language-graphql 解析 80MB 的 GraphQL dump），照样卡死。得配合禁用重型语法包，或者直接用 language-text 这类零解析的兜底方案。
