Sublime Text打开超大文件卡死，需立即执行Set Syntax: Plain Text、Toggle Word Wrap并右键设为Plain Text；用户设置必加"index_files": false、"line_numbers": false、"gutter": false、"highlight_line": false、"draw_white_space": "none"五项降级配置。
Sublime Text 打开超大文件（几百 MB 到 2GB）卡死，不是它“不行”，而是它默认把 access.log 当成 main.py 在认真解析——语法高亮、行号渲染、缩进检测、后台索引全在跑。关掉这四类行为，它就能秒变高效查看器。
已卡住时怎么5秒内恢复滚动？
别等加载完成，直接打断正在执行的高开销流程：
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Set Syntax: Plain Text回车——立刻停掉语法解析和符号树构建 - 再输
Toggle Word Wrap关闭自动换行，避免超长日志行反复计算软断点 - 右键状态栏右下角当前语法名（比如显示
JSON），选Open all with current extension as… → Plain Text，防止下次同后缀文件重蹈覆辙 - 如果
Ctrl+Shift+P已无响应，终端执行subl --safe-mode your_file.log，跳过插件和用户设置，实测 1.2GB 日志 8 秒内可滚动
Preferences → Settings – User 必加的五项硬性降级
这不是“建议优化”，而是只读场景下的最小可行配置。缺一项，CPU 就可能悄悄拉满：
-
"index_files": false——关后台全文索引，否则会默默扫描建倒排表，哪怕你只是想查个 ERROR -
"line_numbers": false和"gutter": false——行号区重绘是卡顿常见源头，尤其光标悬停触发折叠按钮时 -
"highlight_line": false——当前行高亮纯属渲染负担，对大文件毫无定位价值 -
"draw_white_space": "none"——跳过空格/制表符可视化，避免大量字符串切片开销
顺手加上 "scroll_past_end": false，防止滚动到底部时额外分配缓冲区。
为什么设了 large_file_size_limit 还是卡？
这个配置只影响“后续新打开”的文件，且优先级低于其他选项。常见坑点：
-
"large_file_size_limit": 100单位是 MB，设完后仅对 >100MB 文件启用轻量模式；但如果"index_files": true（默认），它仍会在后台扫描全文建索引 -
"detect_indentation": true（默认）会让 Sublime 从头扫到尾猜缩进，对无缩进日志毫无意义，却耗时耗内存 -
"viewport_size": 100000（默认）意味着单次渲染 10 万字符，改成5000可省 95% 渲染内存，但必须配合"word_wrap": false才生效 - 右下角状态栏显示的
JSON或JavaScript是 Sublime 自动猜的，一加载就开扫，必须手动切回Plain Text
哪些插件会在后台偷偷拖垮 Sublime？
即使你关了语法高亮，这些插件仍会扫描整文件触发卡顿，尤其在刚加载完的几秒内：
-
SublimeLinter和BracketHighlighter是头号嫌疑——它们默认不识别「大文件」概念，会照常跑正则或调用外部命令 -
GitGutter默认同步调用 git status，在 GB 级日志里可能 timeout 卡住主线程 - 临时禁用测试：菜单
Preferences → Package Control → Disable Package，挨个试；确认流畅后，再单独启用SideBarEnhancements这类只响应右键/快捷键的轻量插件 - 若必须用
BracketHighlighter，加配置："bracket_highlighter.ignore_syntaxes": ["Plain text"]
真正容易被忽略的是残留缓存——Session.sublime_session 和 Index/ 目录长期积累后会膨胀成隐形性能杀手，不清理，前面所有优化效果直接打五折。
