Sublime打开大文件卡顿的根源是默认启用语法解析、索引和行号等重型功能，关闭这些并设为只读及Plain Text模式，1.2GB日志8秒内可滚动；已卡住时5秒内恢复的方法是执行Set Syntax: Plain Text和Toggle Word Wrap。
Sublime 打开大文件卡顿，不是它撑不住，而是你没让它“别当这是个要编辑的文件”——关掉语法解析、索引、行号这三类默认开启的重型功能，再配合只读加载和外部预处理，1.2GB 日志 8 秒内可滚动。
已卡住时怎么立刻恢复滚动（5 秒内）
别等加载完成，直接干预正在运行的实例：
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Set Syntax: Plain Text回车——立刻终止语法高亮引擎的全量扫描 - 再输
Toggle Word Wrap关闭自动换行，防止超长日志行反复计算软换行位置 - 右键状态栏语言名（如显示
JSON或Log），选Open all with current extension as… → Plain Text，避免下次同后缀文件重蹈覆辙 - 若
Ctrl+Shift+P已无响应，终端执行subl --safe-mode your_file.log：跳过所有插件和用户设置，实测 1.2GB 日志 8 秒内可滚动
哪些配置项改了最立竿见影（Preferences → Settings – User）
很多人加了 "large_file_size_limit": 100 就以为万事大吉，但 Sublime 实际会同时检查多个阈值，且部分选项优先级更高。真正起效的是这几项：
-
"index_files": false——关后台全文索引，这是头号 CPU 杀手 -
"detect_indentation": false——对无缩进日志毫无意义，却要从头扫到尾猜缩进 -
"line_numbers": false和"gutter": false——行号区重绘是卡顿常见源头，尤其光标悬停触发折叠按钮时 -
"highlight_line": false——当前行高亮对大文件纯属渲染负担 -
"draw_white_space": "none"——跳过空格/制表符可视化，避免字符串切片开销 -
"viewport_size": 5000（必须配合"word_wrap": false）——默认 100000 字符，改成 5000 可省 95% 渲染内存
为什么改了设置还是卡？常见坑点
这些细节容易被忽略，但一出错就前功尽弃：
-
"large_file_size_limit"单位是 MB，设为 100 后，超过 100MB 的文件才启用轻量模式；但若"index_files": true（默认），它仍会在后台默默扫描全文建索引 - 某些插件（如
GitGutter、SublimeLinter）不识别大文件逻辑，一加载就启动子进程扫全文，比 Sublime 自身还慢 -
"word_wrap": false必须和"viewport_size": 5000配合，否则超长行仍会拖垮渲染器 - 右下角状态栏显示的
JSON或JavaScript是 Sublime 自动猜的，一加载就开扫，必须手动切回Plain Text
什么时候该放弃 Sublime，换工具？
Sublime 的本质仍是面向编辑的 GUI 编辑器。以下情况请直接切终端或专用工具：
- 文件 > 2GB，或你只是想查
error、timeout、某段 trace ——用less +/error huge.log或grep -n "error" huge.log | tail -500 - 需要实时 tail 日志：
tail -f app.log比任何编辑器都快 - 结构化数据（JSON/CSV）：用
jq或csvkit提取字段，别硬 parse 全文 - Windows 下可考虑
EmEditor（原生支持 GB 级只读）、Linux/macOS 用glogg或vim -u NONE
复杂点在于：很多卡顿不是单一开关能解决的，而是语法猜测、插件监听、渲染缓冲、GPU 加速四层叠加的结果。最容易被忽略的是——你关掉了高亮，但 GitGutter 仍在后台逐行 diff；你设了 large_file_size_limit，但没关 index_files，它照样偷偷建索引。得一层一层剥开看。
