Atom无内存限制配置项，需通过--max-old-space-size设V8堆上限，并必须关闭Tree-sitter、启用largeFileMode、卸载高内存插件，否则参数无效。
Atom 本身不提供“编辑器内存占用限制”这个配置项——它没有像 VS Code 那样的 --max-memory 或内置堆大小控制界面。你真正能干预的，是底层 Electron 运行时的 V8 堆内存上限，以及阻止内存被插件和解析器无节制吃掉。
--max-old-space-size 是唯一有效的启动参数
Electron（也就是 Atom 的运行容器）基于 Chromium + Node.js，其 JavaScript 堆内存由 V8 引擎管理，默认不限上限。Atom 长时间运行、加载大文件、启用 Tree-sitter 后，JS 堆很容易涨到 2–3GB 并持续泄漏。
- 必须通过命令行参数强制设限，例如：
atom --disable-gpu --max-old-space-size=4096
-
--max-old-space-size=4096表示 V8 老生代堆上限为 4GB（单位是 MB） - Windows 上若报
FATAL ERROR: Ineffective mark-compacts near heap limit，可降为3072 -
--disable-gpu必须同时加：某些显卡驱动在启用 GPU 合成时会反复申请/释放显存，触发间接内存泄漏
别只改快捷方式目标——确保每次启动（包括双击图标、终端调用、Git 集成唤起）都带这些参数。Atom 不会从配置文件读取该参数。
关闭 useTreeSitterParsers 比调内存参数更关键
Tree-sitter 解析器虽准确，但对大文件是内存黑洞：
- 它为整份文件构建并维护语法树，节点数随文件长度线性增长，但引用关系呈网状
- 在一个 15MB 的 JSON 日志里，Tree-sitter 常驻内存比 TextMate 高 3 倍以上
- 更致命的是：它阻塞主线程，导致滚动、保存、甚至右键菜单都卡顿，此时你看到的“高内存”只是表象，根源是解析逻辑没退出
必须手动关闭，在 ~/.atom/config.cson（Windows 是 %USERPROFILE%.atom\config.cson）的 * 根节点下写：
*:
core:
largeFileMode: true
useTreeSitterParsers: false改完必须完全退出 Atom 进程（macOS 执行 killall Atom，Windows 用任务管理器结束所有 atom.exe），否则设置不生效。
插件才是内存失控的主因，不是“占用高”，是“不释放”
linter-eslint、atom-ide-ui、file-icons 这类插件：
- 启动后常驻子进程或大量监听文件系统事件
-
linter-eslint每开一个项目就额外占 80–120MB，且不会随文件关闭自动释放 -
file-icons若未开启 “Enable icon caching”，遍历node_modules时会为每个文件生成 SVG 并缓存 DOM 引用，极易堆积到 2GB+
验证是否插件导致：
- 终端运行
atom --safe /path/to/big.log - 如果秒开不卡，说明问题 100% 出在插件，立刻执行：
apm list --installed --bare
然后卸载：-
linter-*系列 -
ide-*系列 minimap-
file-icons（如需保留，务必进其设置页勾选 “Enable icon caching”）
-
真正容易被忽略的是：即使你设了 --max-old-space-size=2048，只要 useTreeSitterParsers: true 且装着 linter-eslint，V8 堆会在几秒内冲破上限并触发崩溃——参数只是兜底，不是替代方案。先砍插件、关 Tree-sitter、启 largeFileMode，再加参数，顺序错了等于白调。
