邮件 API 与工程化发送：高可用发送架构避坑指南
当邮件量从每天几百封涨到百万级，手工在后台点“发送”就不够了。工程化发送解决的是可靠、可观测、可扩展三大问题。
一、SMTP vs API
SMTP 通用但报错信息弱、难追踪；API 发送返回结构化结果、支持模板与批量、便于事件回传。中大型团队建议以 API 为主，SMTP 作兜底。
二、发送架构
- 队列：发送任务入队，削峰填谷
- 限流：按域名信誉与配额平滑发送
- 重试：对临时失败（4xx）指数退避重试
- 幂等：用业务键去重，防止重复发送
三、模板渲染与本地化
模板与数据分离，渲染层支持多语言、多币种、时区。渲染失败应触发告警而非发出残缺邮件。
四、事件 webhook 处理
| 事件 | 用途 |
|---|---|
| open / click | 行为标签、序列推进 |
| bounce | 清洗无效地址 |
| spam complaint | 立即降频并标记 |
| unsubscribe | 同步偏好中心 |
五、监控与告警
监控发送成功率、队列积压、webhook 延迟。队列积压超阈值、发送失败率突增需即时告警。
六、自建 vs 第三方
自建可控但有运维成本；第三方（云邮件服务）省心、送达优化成熟。多数团队应从第三方起步，量级与合规要求极高再评估自建。
总结：工程化不是炫技，而是让“每一封都准时、准确地到达对的人”成为可保证的承诺。
本文由邮件营销知识库整理发布，供运营参考。
