结论：日志正则处理必须分「定位→截断→清理→校验」四步，因日志含多行、混合编码、控制字符等，.默认不匹配换行且.易回溯爆炸，需启用“. matches newline”、用[\s\s]?替代.*?、统一编码与换行符，否则易卡死、漏字段或切错时间戳。
直接说结论：别指望一次正则干完，得拆成「定位→截断→清理→校验」四步走，否则容易卡死、漏字段、或把时间戳错切成两半。
为什么日志里用 .* 会匹配失败甚至崩溃
日志通常跨多行（比如堆栈跟踪）、含混合编码（UTF-8 + BOM + GBK 残留）、还有零宽空格或控制字符。而 . 默认不匹配换行符，.* 在大文件中又极易触发回溯爆炸——Sublime 会卡住几秒甚至无响应。
- 必须勾选
. matches newline（点右下角那个.图标），否则^.*$只能匹配单行 - 改用
[\s\S]*?替代.*?：前者明确包含换行，且非贪婪更安全 - 超过 5MB 的日志，先用
File → Reopen with Encoding → UTF-8强制重载，避免正则在字节层面乱匹配 - 如果替换后出现中文变方块、时间戳错位，大概率是编码没对齐，不是正则写错了
清洗常见日志结构的正则写法
以典型的 Java Spring Boot 日志为例（含时间戳、线程名、日志级别、类名、消息）：
2026-08-19 10:22:34.123 INFO [main] c.e.App - Starting App on DESKTOP-ABC...
- 删掉冗余线程信息（保留
[main]这种关键标识）：
查找：\s+\[([^\]]+)\]\s+→ 替换为：[$1]（前后加空格防粘连） - 提取纯业务消息（去掉前面所有前缀）：
查找：^\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2}\.\d{3}\s+\w+\s+\[[^\]]+\]\s+[\w.]+-\s+→ 替换为空 - 合并连续空行（日志切分后常残留）：
查找：^\s*$(\n\s*$)+→ 替换为：\n（注意勾选. matches newline） - 清理 ANSI 颜色码（如
\x1b[32m）：
查找：\x1b\[[0-9;]*m→ 替换为空（Sublime 支持十六进制转义）
批量提取关键字段时，^ 和 $ 为什么总不生效
Windows 日志复制进来默认是 \r\n 换行，但 Sublime 的 ^/$ 在多行模式下默认只锚定整个文本首尾，不是每行——导致 ^ERROR 找不到任何内容。
- 手动兼容
\r\n：把^ERROR改成(^|\r?\n)ERROR，并确保勾选Regular Expression和. matches newline - 更稳做法：先统一换行符 ——
File → Line Endings → Unix (LF)，再用^ERROR - 中文界面下某些插件会干扰行边界识别，临时切回
Plain Text语法（Ctrl+Shift+P→Set Syntax: Plain Text） - 如果仍不匹配，用
\u000D\u000A显式写\r\n，比依赖自动识别更可靠
大日志文件操作前必须做的三件事
跳过这三步，后面所有正则都可能白做，甚至损坏原始数据。
- 先
Save As备份一份副本，别直接在原文件上狂点Replace All - 用
Ctrl+Shift+P→Set Syntax: Plain Text关掉语法高亮插件，避免它们注入不可见字符干扰正则 - 执行前先
Find All（Alt+Enter），看匹配数量是否合理；若显示“Too many matches”，说明正则太宽泛，得收紧范围（比如加\b或限定前后字符）
真正麻烦的从来不是正则怎么写，而是日志里那些没声明的换行方式、BOM、零宽空格和半角/全角混用的空格——它们不会报错，但会让 $1 引用错位、让 ^ 失效、让替换结果看起来“差不多但就是不对”。处理前花三十秒检查编码和换行符，比事后调试十分钟更省事。
