关闭语法高亮并强制设为Plain Text是最立竿见影的操作，可避免Sublime对大日志文件逐行语法解析导致的卡顿。
关语法高亮 + 强制 Plain Text 是最立竿见影的操作
Sublime 打开几百 MB 的日志就卡死，八成是因为它正在后台逐行跑语法解析——匹配正则、生成着色指令、构建符号树，这些对 app.log 这类纯文本毫无意义，却吃光内存和 CPU。
- 立刻操作：打开文件后，点右下角语言标识（比如显示
Log或JSON），选Open all with current extension as… → Plain Text - 命令面板更快：按
Ctrl+Shift+P，输入Set Syntax: Plain Text回车 - 别忽略后缀继承：一旦设为
Plain Text，同后缀文件下次也会默认用该模式，省得每次都点 - 顺手关掉
word_wrap：超长日志行一开自动换行，渲染引擎会反复计算断点，滚动像幻灯片；菜单View → Word Wrap → Off，或设置里加"word_wrap": false
改 large_file_size_limit 和禁用索引，让 Sublime “主动降级”
默认 10MB 就弹警告，但这个阈值太保守。关键是让它从加载第一字节起就知道：“这是只读大文件”，跳过所有编辑向功能。
- 进
Preferences → Settings，右侧用户设置加："large_file_size_limit": 100,
"index_files": false,
"detect_indentation": false,
"highlight_line": false,
"line_numbers": false
-
large_file_size_limit单位是 MB，设为100后，超 100MB 文件自动不解析语法、不建索引、不猜缩进 -
index_files: false是关键：否则插件如GitGutter或SublimeLinter会偷偷扫全文，CPU 拉满还查不到错 - 别设
large_file_threshold过低（如1048576）：虽能强制只读，但混合编码（GBK + UTF-8）时可能解析错乱，行号全偏移
别用鼠标滚，用 goto_line 和分割视图定位
在 50 万行日志里拖滚动条，本质是反复 seek + 重分配 buffer，延迟明显；而 goto_line 走的是行偏移索引，快一个数量级。
- 快速跳转：按
Ctrl+P，直接输入:123456（冒号开头），回车跳到第 123456 行 - 双窗格协作：按
Ctrl+Shift+2拆左右视图，左边保持头几行看结构/时间戳，右边Ctrl+G定位具体错误行 - 别信
find_in_files扫全量：它会把每行都 load 进内存；先终端跑grep -n "OutOfMemoryError" app.log | head -10，再把行号贴进 Sublime
该换工具时就换，别硬扛 GB 级文件
Sublime 再怎么调，本质仍是面向编辑的 GUI 编辑器。超过 2GB 或需高频正则替换时，它的内存模型和事件循环就不是设计目标了。
- 纯查看：Linux/macOS 用
less（支持/pattern搜索、g到开头、G到结尾），零内存占用；Windows 可用more或git bash里的less - 筛选切片：用
awk、sed或 Python 的linecache模块，比等 Sublime 进度条实在 - 真要编辑：确认是否必须图形界面？
vim -u NONE +1000000 huge.log启动后直接定位，比 Sublime 加载还快
最容易被忽略的一点：配置再细，也改不了 Sublime 把整文件映射进内存的底层逻辑。日志不是用来编辑的，是查的——方向错了，参数调得再密也没用。
