必须关闭 index_files，因其会后台全文扫描建索引，导致内存暴增、cpu 90% 占用且不释放；需在 settings–user 中设为 false 并完全重启生效。
为什么关掉 index_files 是第一件事
不是“建议关”，是必须关。Sublime 默认开启的 index_files 会在后台对整个文件做全文扫描、建倒排索引、解析符号结构——这对千万行日志或单行 JSON 来说，纯属无效劳动。它不等你操作就默默吃掉 1GB+ 内存，CPU 持续 90% 占用，且旧索引上下文不会随文件关闭释放。
实操要点：
-
index_files必须加到Preferences → Settings – User中，并设为false - 改完后必须完全退出 Sublime（不是关闭窗口），再重启才生效
- 副作用是
Ctrl+R（跳转符号）失效，但Ctrl+P（按文件名跳）和Ctrl+Shift+F（文本搜索）仍可用 - 若项目需部分索引，改用
folder_exclude_patterns排除node_modules、logs等目录，比全局关更精准
viewport_size 设成 5000 而不是默认 100000
默认值 viewport_size 是 100000 字符，意味着每次滚动都尝试渲染 10 万字符范围。对超长行或密集文本，这直接触发高频内存分配和字符串切片，卡在光标移动、翻页时特别明显。
实操建议：
- 在用户设置中加入
"viewport_size": 5000，可省掉 95% 渲染内存开销 - 必须配合
"word_wrap": false，否则超长行仍会反复计算断点 - 这个值不是越小越好：低于 2000 可能导致局部刷新撕裂，5000 是实测平衡点
- 它只影响“当前视口”渲染量，不影响查找、跳转或复制功能
别信 large_file_size_limit，真正起效的是语法与渲染开关
很多人加了 "large_file_size_limit": 100 就以为万事大吉，结果打开 1.2GB 的 dump 文件还是卡死。因为 Sublime 实际检查多个阈值，且 index_files、detect_indentation、syntax 这些开关优先级更高——哪怕文件被识别为“大文件”，只要语法高亮开着，它照样逐行着色。
关键动作：
- 右下角点击语法名 →
Open all with current extension as… → Plain Text，避免下次同后缀重蹈覆辙 - 手动执行
Ctrl+Shift+P → Set Syntax: Plain Text，立刻停掉语法解析和符号树构建 - 关掉
"detect_indentation": false，防止它从头扫到尾猜缩进（日志根本没缩进） -
"draw_white_space": "none"和"highlight_line": false不是锦上添花，是避免大量字符串切片和重绘的硬性要求
超过 2GB 就该换工具，别硬拖 Sublime
Sublime 的内存映射 + 按需加载机制，对 2GB 以内文件还能撑住，但超过这个量级，它的事件循环和缓冲区管理就不是设计目标了。你调得再细，也绕不开 GUI 框架本身的内存模型限制。
真实场景建议：
- 纯查看：用
less（Linux/macOS）或more（Windows Terminal），支持/pattern搜索、g到开头、G到结尾，零内存占用 - 定位行号：终端先跑
grep -n "ERROR" app.log | head -20，把行号贴进 Sublime 的Ctrl+G，比全文件 Find 快一个数量级 - 真要编辑：确认是否必须图形界面？
vim -u NONE +1000000 huge.log启动后直接定位，比 Sublime 加载还快 - 批量处理：用
awk或 Python 的linecache模块，别在 Sublime 里等进度条
