sublime打开千万行日志卡死，是因为默认按代码文件处理：逐行正则高亮、建符号索引、检测缩进、渲染gutter图标、gitgutter逐行diff，导致cpu 100%、ui挂起；立刻恢复需三步：set syntax: plain text停解析、toggle word wrap关自动换行、右键设同后缀为plain text；用户设置必加"large_file_size_limit": 100、"index_files": false、"viewport_size": 5000、"detect_indentation": false、"line_numbers": false、"gutter": false，并配合"word_wrap": false；超2gb应改用less/grep等专用工具。
为什么Sublime打开千万行日志会卡死
不是内存不够，是它默认把app.log当main.py在处理：逐行跑正则高亮、建符号索引、检测缩进、渲染每行 gutter 图标、甚至让GitGutter对每一行做 diff。这些动作在 200 万行日志里全开，CPU 占用稳居 100%，UI 线程直接挂起。
立刻恢复滚动的三步干预（已打开文件卡住时）
别等加载完成，当前窗口就能救回来：
- 按
Ctrl+Shift+P输入Set Syntax: Plain Text回车——语法解析器当场停摆 - 再输
View: Toggle Word Wrap关自动换行，超长日志行不再触发软换行重计算 - 右下角语言名（比如显示
Log或JSON）右键 →Open all with current extension as… → Plain Text，避免下次同后缀文件重蹈覆辙
如果命令面板已无响应，直接终端执行 subl --safe-mode huge.log，8 秒内可滚动（实测 1.2GB 日志）。
用户设置里必须加的关键项（Preferences → Settings – User）
光关界面不顶用，得让 Sublime 从第一字节开始就放弃“编辑幻想”：
-
"large_file_size_limit": 100：单位 MB，≥100MB 文件跳过语法分析、折叠、符号索引 -
"index_files": false：头号 CPU 杀手，关掉后SublimeLinter、GitGutter不再后台扫全文 -
"viewport_size": 5000：单次最多渲染 5000 字符（默认 100000），内存占用直降 95% -
"detect_indentation": false：日志没缩进，但它默认要扫完整个文件猜，纯属浪费 -
"line_numbers": false和"gutter": false：千万行下每行生成 DOM 节点是重绘瓶颈
注意："large_file_size_limit" 不影响已打开文件，只对后续新打开生效；"viewport_size" 必须配合 "word_wrap": false，否则超长行仍拖垮渲染器。
别靠滚动条找错误，用索引跳转 + 外部预筛
鼠标滚 200 万行，本质是反复 seek + buffer 重分配，延迟明显；goto_line 走的是预建的行偏移索引，快一个数量级：
- 按
Ctrl+P输入:123456（冒号开头），回车直跳第 123456 行 - 拆左右视图：
Ctrl+Shift+2，左边固定看时间戳格式，右边Ctrl+G定位具体行 - 别在 Sublime 里
find_in_files全量扫——改用终端：grep -n "ERROR" app.log | head -20，拿到行号再贴进 Sublime
真正容易被忽略的是：Sublime 的内存模型和事件循环不是为 GB 级只读场景设计的。超过 2GB，或需要高频正则替换时，它就不是工具，而是障碍本身。
