sublime打开大文件卡顿的根源是默认功能过度解析，5秒内恢复需设纯文本语法并关自动换行；关索引、行号、高亮等五项设置+终端筛选跳转+系统设只读可根治。
Sublime Text 能打开大文件，但默认配置会让它在几十 MB 就卡死——不是不能开，而是它默认把 app.log 当成 main.py 在认真解析。
关语法高亮和自动换行，5 秒内恢复响应
这是最立竿见影的两步，不用改设置、不用重启，打开即生效：
- 点击窗口右下角语言标识（比如显示
JSON或Log），选Open all with current extension as… → Plain Text - 按
Ctrl+Shift+P（macOS 是Cmd+Shift+P），输入Toggle Word Wrap回车
语法高亮会逐行跑正则匹配，word_wrap 会对每行超长文本反复计算软换行位置——这两项一关，滚动不幻灯片、光标不消失、搜索不假死。注意：Plain Text 设置会继承后缀，下次再开同类型文件就自动轻量加载。
必须关掉的五项后台功能
很多人加了 large_file_size_limit 就以为万事大吉，结果还是卡。真正拖慢的是这些默认开启、却对日志类文件毫无意义的后台行为：
-
"index_files": false：禁用全文符号索引，否则打开瞬间 CPU 拉满 -
"detect_indentation": false：避免从头扫到尾猜缩进，日志文件根本没缩进 -
"line_numbers": false和"gutter": false：行号区重绘是卡顿常见源头，尤其悬停触发折叠按钮时 -
"highlight_line": false：当前行高亮纯属渲染负担，查日志不需要
这些要写进用户设置（Preferences → Settings – User），不是临时开关。别信“我就看一眼”，只读场景下它们全该关。
为什么改了阈值还是弹窗？ask_before_opening_large_files 必须设为 false
即使你把 large_file_size_limit 设到 100，Sublime 默认仍会弹出 The file is too large to open 确认框——点了 Yes 也没用，它照样偷偷建索引、高亮、检测缩进。
在用户设置里加上这一行：
{"ask_before_opening_large_files": false}
配合 "index_files": false 使用，才能真正跳过所有后台分析。否则弹窗只是个幌子，后台进程照常吃满 CPU。
别硬扛 GB 级文件，subl --safe-mode + 外部预处理才是正解
2GB 的 app.log 不是用来编辑的，是拿来定位问题的。指望 Sublime 编辑它，就像用计算器跑机器学习——方向错了，调参没用。
- 临时查看：终端执行
subl --safe-mode /path/to/huge.log，跳过所有插件和自定义设置，实测 1.2GB 日志 8 秒内可滚动 - 先筛再开：用
tail -n 5000 app.log | grep "ERROR" > errors.log提取关键片段，再用 Sublime 打开errors.log - 拆分查看：运行
split -b 500M huge.log part_，生成part_aa、part_ab等小文件，再逐个subl part_aa
真正容易被忽略的是：系统级“只读”属性比任何设置都管用。右键文件 → 属性 → 勾选“只读”，Sublime 会自动禁用撤销栈、缓存写入和大部分后台分析——这比改十项配置还彻底。
