应使用非贪婪、不依赖行首的正则.*?(550|450|554|421|503).*?匹配SMTP错误码，配合分组.*?(<[^>]+>).*?(550|450|554|421|503).*?:([^$]*)$提取邮箱、错误码、描述三元组，并注意BOM编码、换行符及性能优化。
为什么直接用 ^.*?550.*?$ 会漏掉关键异常行
日志里真正报错的那行往往不是以错误码开头，而是夹在中间——比如 RCPT TO:<user@domain.com> 550 5.1.1 User unknown。用 ^.*?550.*?$ 只能匹配整行以 550 开头的（几乎不存在），实际要的是「包含 550、450、554 等 SMTP 错误码」的任意行。
推荐正则：.*?(550|450|554|421|503).*?，启用 g 和 i 标志（Sublime 默认支持）。它不依赖行首，也不要求连续字符，只要整行含任一错误码就捕获。
- 别忘了勾选 Sublime 的
Regex模式（右下角按钮）和Match Case（除非确认日志全小写） - 如果日志带时间戳前缀（如
[2024-03-12 14:22:03]），这个正则仍有效——.*?自动跳过前面内容 - 避免用
.*550.*：贪婪匹配可能跨多行，尤其日志含换行符时；.*?的非贪婪更安全
如何一次性提取邮箱地址 + 错误码 + 错误描述三元组
单靠高亮不够，得结构化提取。用分组捕获最直接：.*?(<[^>]+>).*?(550|450|554|421|503).*?:(.*)$
这个表达式假设典型格式为：... RCPT TO:<bad> ... 550 ... : User unknown</bad>。三个括号分别对应邮箱、错误码、描述。
- 替换时用
$1\t$2\t$3，导出为 TSV 表格，Excel 或 pandas 可直接加载 -
<[^>]+>比<.+?>更安全：防止匹配到嵌套尖括号或空标签 - 如果邮箱没被
<>包裹（如纯bad@domain.com），换成([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}) - 结尾
$很关键——确保只捕获当前行内容，避免跨行误吞
Sublime 的 Find All 和 Replace All 性能差异在哪
处理百万行日志时，Find All（Ctrl+Shift+F）只是高亮+列表展示，内存占用低；而 Replace All（Ctrl+H → Replace All）会实际生成新文本，可能卡死或崩溃。
- 先用
Find All确认正则准确：看命中的行是否全是目标异常，有误匹配就调正则 - 真正导出数据时，用
Find All后按Ctrl+Shift+P→ 输入Copy Selected Text，再粘贴到新文件——比Replace All更稳 - 如果必须用
Replace All，务必先备份原文件；Sublime 对超大文件（>50MB）的替换操作无进度提示，容易误判为假死 - 禁用插件（如 GitGutter、SideBarEnhancements）可提速——它们会在每次文本变更时触发额外扫描
为什么有些 550 错误被过滤掉了？检查日志编码和 BOM 头
部分邮件网关（如某些 Postfix + Dovecot 组合）输出的日志带 UTF-8 BOM（\ufeff），Sublime 默认识别为 UTF-8，但正则引擎可能把 BOM 当作不可见字符干扰匹配位置。
- 打开 Sublime →
File → Reopen with Encoding → UTF-8（不是 UTF-8 with BOM） - 用
Ctrl+Shift+P→Convert to UTF-8强制清除 BOM - 验证方法：在日志开头手动输入
test，若光标无法定位到第 0 列，大概率有隐藏 BOM 或 \r\n 混用 - Windows 日志常见
\r\n，Linux 是\n；Sublime 默认按系统换行符解析，但正则里的.*?能跨 \n，所以一般不影响——除非你用了^/$且未开启m（multiline）标志
真正麻烦的是混合错误码语义：比如 450 4.7.1 Client host rejected 是临时拒绝，550 5.1.1 是永久失败，但正则本身不区分——后续分析得靠人工或脚本二次分类。别指望一条正则解决所有归因问题。
