Sublime Text 打开超大文本文件卡顿的根源在于默认高耗能功能，应关闭语法高亮、自动换行，设为 Plain Text，并在用户设置中配置 large_file_size_limit、index_files 等关键项禁用后台分析。
Sublime Text 能打开超大文本文件，但默认配置会卡死或崩溃——不是它不行，而是你没关掉那些“默认就开”的高耗能功能。关键不在“怎么开”，而在“怎么让它别当这是个要编辑的代码文件”。
关语法高亮 + 强制 Plain Text 是最立竿见影的操作
语法高亮对大文件是性能杀手：Sublime 会逐行解析结构、匹配规则、生成着色指令，几十 MB 的日志一开就卡住不动。自动换行（word_wrap）在超长行场景下还会让渲染引擎反复计算断点，滚动直接变幻灯片。
- 打开大文件后，立刻点击右下角语言标识（如
JSON或Log），选 Open all with current extension as… → Plain Text - 或者用命令面板：
Ctrl+Shift+P→ 输入Set Syntax: Plain Text - 顺手关掉自动换行：
View → Word Wrap → Off，或在用户设置里加"word_wrap": false
改核心配置项，让 Sublime “主动降级”处理大文件
默认的 large_file_size_limit 是 10MB，太保守；不改的话，哪怕你手动点了“Yes”打开，它仍可能偷偷加载索引、检测缩进、高亮当前行——这些全得关。
- 进
Preferences → Settings，在右侧用户设置中加：
{
"large_file_size_limit": 100,
"index_files": false,
"detect_indentation": false,
"draw_white_space": "none",
"line_numbers": false,
"highlight_line": false,
"scroll_past_end": false,
"show_minimap": false,
"gutter": false
}
large_file_size_limit 单位是 MB，设为 100 后，超过 100MB 的文件会自动跳过语法分析和索引index_files: false 防止后台构建全文符号数据库，CPU 不再拉满detect_indentation: false 对日志类无缩进文本毫无意义，却要扫描整文件，必须关只读 + 外部预处理，才是真正实用的取舍
GB 级日志不是用来编辑的，是查的。指望 Sublime 编辑 2GB 的 app.log 就像用记事本跑数据分析——方向错了，再调参也白搭。
- 系统级只读更彻底：右键文件 → 属性 → 勾选“只读”（Windows/macOS 都有效），Sublime 会自动禁用撤销栈和缓存写入
- 命令行先筛再开才是正解，比如：
tail -n 5000 app.log | grep "ERROR\|Exception" | head -n 200 > errors_recent.log
split -b 500M huge.log part_，生成 part_aa、part_ab 等小文件慎用插件 + 避免全局生效的陷阱设置
很多插件（比如 GitGutter、LSP、AutoSave）会在后台持续监听、解析、IO，对大文件是隐形拖累。而像 "default_read_only": true 这种全局设置，一开就所有文件都锁死，连临时改个配置都麻烦。
- 临时禁用插件：
Ctrl+Shift+P→ 输入Disable Package，挑几个常驻后台的关掉 - 用
--safe-mode启动验证是否插件导致卡顿：subl --safe-mode your_huge_log.log - 别碰
"default_encoding"或"fallback_encoding"盲调，编码探测失败反而更卡；UTF-8 日志就保持默认
最容易被忽略的一点：改完设置后没重启 Sublime，或者改的是左侧默认设置而非右侧用户设置——所有优化都白做。还有人把 large_file_size 和 large_file_size_limit 混用，前者在新版里已弃用，只认后者。
