Sublime大文件卡顿根源是默认当代码解析，关语法高亮、索引、缩进检测、gutter渲染、自动换行五项可解决90%问题；已卡死时切Plain Text、关Word Wrap或safe-mode启动，配合index_files、viewport_size、detect_indentation、large_file_size_limit四项配置及syntax-specific设置实现高效查看。
Sublime 编辑大文件卡顿，不是软件不行，也不是你机器差，而是它默认把 access.log 当成 main.py 在逐行解析——语法高亮、索引、缩进检测、gutter 渲染全开，一碰几百 MB 就 CPU 拉满、UI 冻结。关掉这五类行为，90% 卡顿当场消失。
已卡死时怎么 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，避免下次同后缀文件重蹈覆辙 - 如果命令面板已无响应，终端执行
subl --safe-mode your_file.log：跳过所有插件和用户设置，实测 1.2GB 日志 8 秒内可滚动
Preferences → Settings – User 必加的四条硬核配置
这些不是“越狠越好”，而是精准切断性能杀手链：
-
"index_files": false：禁用后台全文索引，否则GitGutter、SublimeLinter仍会偷偷启动子进程扫全文 -
"viewport_size": 5000：默认值是100000，砍掉 95% 渲染字符数；但必须配合"word_wrap": false才生效，否则超长行仍拖垮渲染器 -
"detect_indentation": false：对无缩进日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存 -
"large_file_size_limit": 100：单位是 MB，设为 100 后，超过 100MB 的文件才启用轻量模式；设太小（如50）会让日常.json文件也被误判，太大（如1000）可能错过真正要编辑的大文件
为什么全局关 line_numbers 是坑？该用 syntax-specific 设置
你不需要对所有文件都关行号，日常写 Python 时仍需定位；但打开 app.log 时就得静默加载：
- 打开一个大日志文件，确认右下角显示语法为
Plain Text或Log - 执行
Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如Plain Text.sublime-settings） - 在里面写入：
{ "line_numbers": false, "gutter": false, "highlight_line": false }
容易被忽略但一出错就前功尽弃的细节
这些点不显眼，但决定调参是否真起效：
-
"large_file_size_limit"只影响后续新打开的文件，对已卡住的当前文件完全无效 - 某些插件（如
GitGutter、SublimeLinter）不识别大文件逻辑，一加载就启动子进程扫全文，比 Sublime 自身还慢 -
"word_wrap": false和"viewport_size": 5000必须同时存在，缺一不可；否则超长行依然触发大量软换行计算 - 右下角状态栏显示的
JSON或JavaScript是 Sublime 自动猜的，一加载就开扫，必须手动切回Plain Text
真正卡在 GB 级别时，别硬扛——subl 不是日志查看器，less、grep、tail -f 才是第一道工序。优化是让 Sublime “别当这是个要编辑的文件”，而不是让它“强行编辑它”。
