sublime text 打开大日志卡死主因是默认启用语法解析等重型功能，设为 plain text 并配置 large_file_size_limit、index_files、viewport_size 等 5 项参数可秒开 2gb 日志；超 2gb 应换 less/grep/jq 等专用工具。
Sublime Text 打开千万行日志卡死，不是它撑不住，而是你让它“当代码在编译”——语法高亮、GitGutter逐行diff、自动检测缩进、建符号索引、渲染每行 gutter 图标，全在后台疯狂跑。关掉这些，2GB 日志也能秒开滚动。
Set Syntax: Plain Text 必须第一步做
这是所有优化的前提，不做这步，后面配置全白搭。Plain Text 不只是关高亮，它直接停掉 sublime-syntax 解析器、跳过行匹配正则、阻止插件（如 GitGutter）扫描全文。
- 已打开文件卡住时：按
Ctrl+Shift+P→ 输入Set Syntax: Plain Text→ 回车，滚动立刻恢复 - 右下角语言名（如显示
Log或JSON）右键 →Open all with current extension as…→Plain Text，下次同后缀自动轻量加载 - 别装“Log Highlighter”类插件——它们自带的正则规则一跑就是 O(n²)，50MB 日志就能让 CPU 锁死
用户设置里这 5 项不能少
Preferences → Settings – User 中必须加，且注意顺序和单位。这些不是“可选优化”，是让 Sublime 从第一字节开始就放弃编辑幻想的硬开关。
-
"large_file_size_limit": 100：单位 MB，≥100MB 文件跳过语法分析、折叠、符号索引；注意：只对新打开文件生效，已打开的不刷新 -
"index_files": false：头号 CPU 杀手，关掉后 SublimeLinter、GitGutter、LSP 插件不再后台扫全文 -
"viewport_size": 5000：单次最多渲染 5000 字符（默认 100000），内存占用直降 95%；但必须配合"word_wrap": false，否则超长日志行仍触发软换行重计算 -
"detect_indentation": false：日志没缩进，但它默认要扫完整个文件猜 tab/空格，纯属浪费 -
"line_numbers": false和"gutter": false：千万行下每行生成 DOM 节点是重绘瓶颈，关掉后滚动帧率翻倍
goto_line 比滚动条快一个数量级
鼠标滚 200 万行，本质是反复 seek + buffer 重分配；goto_line 走的是预建的行偏移索引，延迟几乎为零。尤其适合定位错误时间戳附近行。
- 按
Ctrl+P→ 输入:123456（冒号开头 + 行号）→ 回车，直跳第 123456 行 - 拆左右视图：
Ctrl+Shift+2，左边固定看时间戳格式（如2026-06-08 14:30:），右边Ctrl+G定位具体行 - 如果
Ctrl+P输入:n无响应，说明当前文件未建行索引——此时需先确认是否已设为Plain Text且large_file_size_limit已生效
超过 2GB 就别硬扛了
Sublime 再怎么调参，本质仍是内存映射型编辑器。2GB 日志加载后常驻内存 >3GB，加上插件缓存极易触发系统 swap，UI 响应退化成“点击后等三秒才动”。这时候真不是配置问题，是工具选错了。
- 只读查看场景：用
less +F huge.log实时追尾，或grep -n "ERROR" huge.log | head -20预筛再开 - 需要上下文：
sed -n '123450,123470p' huge.log | subl -管道传入指定行段 - 结构化日志（JSON Lines）：用
jq -r '.timestamp, .message' huge.jsonl | head -50提取字段再处理
最易被忽略的一点：large_file_size_limit 和 viewport_size 是协同生效的——前者决定“要不要建索引”，后者决定“建多少”，漏掉任一，都可能在某次打开时突然卡死，而你根本想不起上周改过哪行配置。
