Sublime Text 打开大文件卡顿可通过关闭语法高亮、自动换行、索引等非必要功能，设置大文件阈值、禁用插件并配合外部预处理（如 grep/tail）解决，核心是“关什么比开什么更重要”。
Sublime Text 打开大文件卡顿，不是它“不行”，而是默认配置全为小文件编辑服务——关掉语法高亮、索引、行号这些“装饰性负担”，再配合轻量加载策略，百兆级日志、导出数据完全能秒开不卡。
关闭语法高亮和自动换行（最立竿见影）
语法高亮对大文件是性能杀手：Sublime 会逐行解析结构，几十MB的 JSON 或日志一开就卡死；自动换行（word_wrap）在超长行场景下会让渲染引擎反复计算断点，滚动直接拖慢三倍。
- 临时关闭当前文件：点击窗口右下角语言标识（如
JSON），选 Open all with current extension as… → Plain Text - 或用命令面板：
Ctrl+Shift+P→ 输入Set Syntax: Plain Text - 关自动换行：
View → Word Wrap → Off，或在用户设置中加"word_wrap": false - 别信“只是看一眼”，哪怕只开一次，也建议顺手关掉——下次同后缀文件会继承该设置
修改核心配置项（防加载崩溃）
Sublime 默认对超过 10MB 的文件弹警告并限制功能，但这个阈值太保守。关键是让编辑器“别当它是可编辑文件”，而是一个只读查看器。
- 打开
Preferences → Settings，在右侧用户设置中加入：
{
"large_file_size_limit": 100,
"large_file_size": 100,
"huge_file_size": 10,
"index_files": false,
"detect_indentation": false,
"draw_white_space": "none",
"highlight_line": false,
"line_numbers": false,
"scroll_past_end": false
}
large_file_size_limit 是启用“轻量模式”的开关（单位 MB），设为 100 后，超 100MB 文件自动跳过语法分析；index_files: false 禁用后台全文索引，避免打开瞬间 CPU 拉满；detect_indentation: false 阻止它扫描整份文件猜缩进——这对日志类无缩进文本毫无意义，却极耗时。
用只读 + 外部预处理替代硬扛（真正实用的取舍）
GB 级日志不是用来“编辑”的，而是用来“查”的。指望 Sublime 编辑 2GB 的 app.log 就像用记事本跑数据分析——方向错了，再调参也白搭。
# 提取含 error 的最近 500 行 tail -n 5000 app.log | grep "ERROR" | head -n 500 > errors_recent.log拆分超大文件（每 10 万行一个）
split -l 100000 app.log apppart
用 Sublime 打开生成的小文件，而不是原文件
subl errors_recent.log
注意：grep 和 tail 在 macOS/Linux 下原生支持，Windows 用户可用 Git Bash 或 WSL；别在 Sublime 里用 Find in Files 搜 GB 文件——它默认有 find_in_files_max_bytes 限制，且极易卡死。
插件与运行环境（容易被忽略的隐性瓶颈）
很多卡顿根本不是文件大，而是插件在后台“默默搞事”。比如 GitGutter 会为每个文件调用 git status，遇到大日志就反复阻塞；LSP 类插件尝试加载语言服务器解析，直接内存爆满。
- 启动时按住
Ctrl进入安全模式，测试是否变快——如果快了，说明插件是元凶 - 在用户设置中禁用非必要插件：
"ignored_packages": ["GitGutter", "Anaconda", "Vintage"] - 确认你用的是 64 位 Sublime Text：32 位版本内存上限约 2GB，打开 800MB 文件就可能触发 OOM
- 缓存目录（
%APPDATA%\Sublime Text\Cache或~/Library/Caches/Sublime Text）定期清空，旧索引残留常导致莫名卡顿
真正关键的一点：没有“一劳永逸”的配置。大文件场景永远是“关什么”比“开什么”更重要——别舍不得关掉行号或高亮，它们对排查问题毫无帮助，只拖慢你找关键字的速度。
