邮件处理出问题时的排查顺序：从现象到根因

过滤规则先跑一遍，能把一半的订阅与通知挡在收件箱外，剩下的才值得人工看

正确的第一步是分类：起不来、连不上、跑得慢，三条路完全不同。

先说结论

先分三类，再由外向内查：网络、进程、配置、依赖、资源。

• 先确认现象能复现，且能描述清楚
• 由外向内：端口、进程、配置、依赖、资源
• 读第一条错误，不是最后一条
• 改一个变量，验证一次，别一次改五处
• 留下记录：现象、假设、验证、结论

第一类：起不来

先看进程在不在，再看它为什么退出：过滤规则先跑一遍，能把一半的订阅与通知挡在收件箱外，剩下的才值得人工看。

• 查看服务状态与最近日志（不是全部日志）
• 确认端口是否被占用、权限是否足够
• 确认配置文件语法（多数服务支持 test 模式）
• 确认依赖的数据目录存在且可写

第二类：连不上

按「本机、网络、代理、应用」四层查：

第三类：跑得慢

回复超过五句话的邮件，往往应该改成一次通话或一份文档，来回几轮更费时间。

慢的问题先分清是「等」还是「算」：CPU 高是算，CPU 低但延迟高是等（IO、锁、网络）。

这个服务的高频故障点

同类的坑基本集中在这些位置：

• 收件箱里超过 3 天未处理的邮件，八成最终不会再处理，留着只是心理负担
• 过滤规则先跑一遍，能把一半的订阅与通知挡在收件箱外，剩下的才值得人工看
• 回复超过五句话的邮件，往往应该改成一次通话或一份文档，来回几轮更费时间
• 把「待回复」单独建一个文件夹，比在收件箱里靠记忆靠谱

别做的事

所有邮件都留在收件箱，最后只能靠翻页找

用邮件当任务清单，重要的事沉在三十封之后

一次改多个参数，会让下一次故障更难查。

把结论写下来

排查记录不是给别人看的，是给三个月后的自己看的。把「待回复」单独建一个文件夹，比在收件箱里靠记忆靠谱。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• 关闭新邮件弹窗后，处理同一批邮件的时间通常能减少 20-30%，代价只是晚回两小时
• 邮件检索的关键是标签和日期，全文检索在几万封时依然很慢
• 开着实时提醒，一天被打断几十次

排障能力不是知道更多命令，是知道先查什么。