发送状态先落库：优先降低重复投递风险 发 送 状 态 先 落 库 ： 优 先 降 低 重 复 投 递 风 险

发一封信、然后记一笔"已发",还是先记一笔、再发?两个顺序都能完成投递，但中断时留下的状态不同，需要在设计时就决定如何处理。

先发后记:如果崩在中间,信发出去了但没记录。下一轮扫到"未发",于是再发一次。客户收到两封一模一样的开发信。

先记后发:如果崩在中间,记录写了但信没发出去。下一轮扫到"已发",于是跳过。客户少收一封。

这两种错误的业务代价不同。重复投递可能引起投诉，影响客户体验与发信域名信誉；漏发则需要先核对记录与外部结果，再决定是否补发，不能直接把下一轮重试当成补救。

所以顺序定成先记后发，优先降低重复投递风险。数据库提交与 SMTP 投递不是同一笔事务，先后顺序本身无法证明任何故障下都不重复；它保留的是一种取舍，以及结果未知时需要人工核对的边界。