必须禁用 Tree-sitter 解析器（useTreeSitterParsers: false）并启用 largeFileMode: true，关闭 softWrap、showInvisibles、scrollPastEnd，卸载 linter/ide/minimap 等重型插件，才能使 Atom 流畅打开大文件。
Atom 打开大文件时语法高亮不是“要不要开”的问题，而是开了就卡、不开又看不清——根本矛盾在于 Tree-sitter 解析器和插件在大文件中会持续构建语法树，主线程直接被拖垮。必须禁用高亮逻辑本身，改用轻量文本渲染模式，再按需局部启用。
为什么 useTreeSitterParsers: false 是硬性前提
Tree-sitter 默认开启（useTreeSitterParsers: true），它对 JS/TS/XML 等语言解析更准，但代价是：首次加载 10MB JSON 就要构建完整语法树，内存暴涨、滚动掉帧、保存失败全是它引发的。关掉后回退到 TextMate 高亮，虽不支持 JSX 嵌套或复杂正则捕获组，但对日志、CSV、JSONL、XML 等纯数据类文件，颜色区分完全够用。
- 必须手动写进
~/.atom/config.cson（Windows 是%USERPROFILE%\.atom\config.cson）的core:块下，不能靠自动触发 - 改完必须彻底退出 Atom 进程（不是关窗口），否则已打开文件不会切换模式
- 如果仍想保留基础语法着色，只启用轻量包如
language-log或language-xml，别留language-javascript或language-typescript
怎么让 largeFileMode 真正生效
largeFileMode: true 不是“优化开关”，它是绕过整套 IDE 渲染逻辑的逃生通道：跳过行号计算、折叠状态初始化、装饰器注入。但它不会自动激活——二进制头、无换行符日志、或语法解析器报错都会让它失效。
- 在
config.cson根节点下明确写：core: { largeFileMode: true, useTreeSitterParsers: false } - 不要依赖 >2MB 自动触发；哪怕你只开 5MB 的 access.log，也得手动钉死
- 已打开的大文件不会热切换模式，必须重新用命令行加载：
tail -n 2000 app.log | atom -
哪些 editor 渲染选项一开就卡，必须关
这三项不是“显示偏好”，是 DOM 渲染炸弹：
-
softWrap: false：软换行会让 Atom 对每段长文本强制计算换行位置并插入额外 DOM 节点，10MB 文件滚动一屏就触发 800ms+ 的TextEditorComponent.render -
showInvisibles: false：显示空格/制表符需渲染大量 SVG 元素，大文件下直接拖慢重绘 -
scrollPastEnd: false：底部留白区域会触发额外布局计算，尤其在超长单行日志里极易 OOM
全部加到 config.cson 的 editor: 块下，别漏缩进。
为什么插件清理比调参数更立竿见影
打开 50MB 日志后 CPU 满载、界面冻结、控制台报 RangeError: Maximum call stack size exceeded，90% 是 linter-eslint、atom-ide-ui、minimap 在后台同步扫描内容导致的。它们根本不区分文件大小，一加载就开干。
- 先验证：终端执行
atom --safe /path/to/big.log，如果秒开，就是插件问题 - 卸载命令必须带
--force防残留：apm uninstall linter-eslint --force - 必须卸载：
linter-*、ide-*、minimap、highlight-line；file-icons若保留，务必勾选 “Enable icon caching” - 别信“禁用”，要
uninstall；禁用只是停用，代码仍在内存里监听事件
真正的大文件（>50MB）不适合在 Atom 里编辑，它的定位是代码写作，不是日志分析工具。能用 head/grep/jq 预处理，就别双击打开全量文件。
