Sublime Text 打开大文件卡死的根本原因与性能提升方案
为什么 Sublime Text 打开大文件会卡死？
这事儿其实挺常见的，很多人第一反应是内存不够，但真相往往并非如此。根本原因在于，Sublime Text 默认会火力全开——语法高亮、行号显示、代码折叠、自动补全这些我们平时写代码离不开的功能，在面对一个几百兆的日志或数据文件时，就变成了性能杀手。它会触发海量的文本分析，直接把 subl 进程的 CPU 占用率推到 100%，界面自然就“冻”住了。所以，问题不是文件“打不开”，而是编辑器“不敢动”。
用 --safe-mode 启动跳过所有插件和自定义设置
当你需要临时快速查看一个动辄几百兆的 access.log 或者数据库导出文件时，这是最立竿见影的方法。它相当于让 Sublime Text 进入“极简模式”。
- macOS：在终端里执行
subl --safe-mode /path/to/bigfile.log - Windows：在命令提示符里运行
subl.exe --safe-mode "C:\data\huge.csv" - Linux：在终端输入
subl --safe-mode /var/log/syslog
需要留意的是，--safe-mode 不会加载任何通过 Package Control 安装的插件，也不会读取你的个人偏好设置文件。不过，基础的编辑能力，比如搜索、跳转和保存，都还在。实测下来，用这个方法打开一个 1.2GB 的日志文件，从完全卡死到能够流畅滚动，时间可以缩短到 8 秒以内。
禁用语法高亮和行号（关键性能开关）
即便不进入安全模式，手动关闭下面这两个“吃资源”的大户，也能让性能得到显著改善。在文件已经打开的状态下，按下 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS）调出命令面板，然后输入并执行：
View: Toggle Syntax Highlighting—— 关闭后，文件会切换到Plain Text模式，不再进行耗时的关键字解析。View: Toggle Line Numbers—— 行号的渲染本身就需要为每一行生成一个 DOM 节点，对于千万行级别的文件来说，这绝对是个沉重的负担。
如果想设置得更彻底一些，可以打开用户设置文件（Preferences → Settings – User），直接加入下面两行配置：
{
"syntax": "Packages/Text/Plain text.tmLanguage",
"line_numbers": false
}
⚠️ 这里有个小提醒：不建议把 "line_numbers": false 设为全局默认值。这个操作最好只在处理大文件时临时切换，否则在日常编辑小文件时，你会失去快速定位的参照，反而得不偿失。
用 large_file_threshold 提前拦截自动加载
Sublime Text 其实内置了防卡顿的机制，只是它的默认阈值（10MB）在今天看来有点太低了，导致稍微大点的文件就会弹出警告，但最终还是会被强行加载。调整这个阈值，可以让 Sublime 在打开文件之前就自动切换到轻量模式。
- 打开用户设置：
Preferences → Settings – User - 加入这一行：
"large_file_threshold": 262144000（这个数字代表 250MB） - 重启 Sublime Text 使设置生效
设置之后，任何超过 250MB 的文件都会被自动以无语法高亮、无代码折叠、无自动换行的“纯净”模式打开，响应速度几乎可以媲美终端里的 less 命令。当然，这个值需要权衡：设得太高（比如 1GB），可能会错过真正需要编辑的大文件；设得太低（比如 50MB），又可能让日常的代码文件被误判，影响体验。
话说回来，最棘手的其实是混合场景。比如，你手头有一个 300MB 的 JSON 导出文件，你既需要快速跳转到特定字段，又不想丢失文件的结构信息。这时候就得承认，没有工具是万能的。对于这种需求，或许组合使用 jq 命令行工具加上 less -S，或者转向 VS Code 的「Large File Optimizations」功能，会是更稳妥的选择。
