直接搜索 error/warn 卡顿或漏匹配，是因为 sublime 默认将日志当代码处理，触发 gitgutter、brackethighlighter、sublimelinter 等插件后台扫描；应先切为 plain text 语法、关闭索引与换行，再用精准正则匹配错误级别行并高亮，最后通过多光标提取导出。
为什么直接搜 ERROR/WARN 会卡或漏匹配
不是正则写得不对，是 Sublime 默认把日志当代码在处理：每搜一次，GitGutter 在后台逐行 diff、BracketHighlighter 对长行做括号匹配、SublimeLinter 还在扫全文件 lint。这些动作叠加起来，50MB 日志里搜 ERROR|WARN 可能卡住 10 秒以上，甚至命令面板无响应。
更麻烦的是，原始日志里常混着 ERROR_LOG、WARNING_LEVEL 这类非错误词，用简单 ERROR|WARN 会误标；而真正的堆栈异常（比如多行 Traceback）又会被默认的单行搜索漏掉。
- 先按
Ctrl+Shift+P输入Set Syntax: Plain Text回车，停掉所有语法解析器和插件扫描 - 再确认用户设置里已加
"index_files": false，否则 GitGutter 仍会偷偷建索引 - 搜索前关掉
word_wrap（View: Toggle Word Wrap），避免超长日志行触发软换行重计算
用正则精准锚定错误级别行
日志里真正可分类的“错误行”，通常是带明确级别标识的开头行，比如 [ERROR]、WARN —、level=error。靠 \b(ERROR|WARN|CRITICAL)\b 容易误伤，得结合边界和常见格式。
推荐这几个实测有效的模式（全部启用 Regular Expression 模式）：
-
^\[?(ERROR|WARN|CRITICAL|FATAL)\]?:?\s+：匹配行首带方括号或冒号的级别标识 -
^\s*(INFO|DEBUG|WARNING|ERROR)\s*[:\-—]\s*：适配ERROR — request failed这类分隔符风格 -
"level"\s*:\s*["']?(error|warn|critical)["']?：专抓 JSON 格式日志里的 level 字段
输完回车后立刻点 Find All，再按 Ctrl+Shift+K（Windows/Linux）标黄所有匹配行——标记不随关闭消失，下次打开还在。
批量提取并导出分类结果
光高亮没用，得把错误行抽出来单独分析。Sublime 原生不支持导出匹配结果，但可以用多光标 + 替换实现“提取到新标签页”：
- 先用上面任一正则
Find All，确保所有目标行被选中 - 按
Ctrl+Shift+L把每行转成独立光标 - 按
Home跳到行首，Shift+End选中整行（或直接Ctrl+Shift+→选到行尾） - 按
Ctrl+X剪切，Ctrl+N新建标签页，Ctrl+V粘贴——现在你有了纯错误行列表
如果想按级别拆成多个文件，替换时用捕获组：^\[?(ERROR)\]?:?\s+(.*)$ → 替换为 ERROR:$2\n，再用 Sort Lines + Remove Duplicate Lines 做去重统计。
跳过滚动，直接定位错误密集区
鼠标拖滚动条找错误，在百万行里本质是反复 seek + buffer 重分配，延迟明显。真正快的方式是利用 Sublime 预建的行偏移索引：
-
Ctrl+P输入:123456（冒号开头 + 行号）直跳第 123456 行 - 查完一批错误后，用
Ctrl+Shift+P→Next Mark快速跳到下一个标黄行 - 如果错误集中在某段时间，先用终端预筛：
grep -n "ERROR" app.log | head -50，拿到前 50 行号，挨个Ctrl+P跳转
注意：Ctrl+P 输入行号的前提是文件已建好行索引——这只有在设为 Plain Text 且 large_file_size_limit 生效后才会触发。如果输入 :123456 没反应，先检查右下角是否显示 Plain Text，再确认用户设置里 "large_file_size_limit": 100 已保存。
