关闭语法高亮并强制设为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 走的是行偏移索引，快一个数量级。

AI Surge Cloud

AI Surge Cloud是一款面向企业数据科学和 ModelOps 的无代码决策智能平台。

下载

• 快速跳转：按 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 把整文件映射进内存的底层逻辑。日志不是用来编辑的，是查的——方向错了，参数调得再密也没用。