本文介绍在 golang 渲染服务场景下，通过 sendgrid 的批量 rest api（单次请求携带最多 1000 封邮件）替代 smtp 或单封 rest 请求，实现每分钟万级邮件吞吐的最优实践。
本文介绍在 golang 渲染服务场景下，通过 sendgrid 的批量 rest api（单次请求携带最多 1000 封邮件）替代 smtp 或单封 rest 请求，实现每分钟万级邮件吞吐的最优实践。
当你的系统已具备独立的邮件模板渲染能力（例如基于 Go 的服务完成数据注入与 HTML 合成），后续需将大量已渲染邮件（如每日 60 万封）高效投递至 SendGrid 时，通信协议的选择直接决定整体吞吐瓶颈。实测与 SendGrid 官方推荐均表明：使用 v3 REST API 的批量发送模式（Batched API）是当前最高效、最稳定的选择，远优于单封 REST 调用或传统 SMTP。
✅ 推荐方案：SendGrid v3 批量 REST API（/mail/send）
SendGrid 的 /v3/mail/send 端点支持单次请求提交最多 1000 封独立邮件（注意：非 1000 个收件人，而是 1000 个完整邮件对象，含不同收件人、主题、内容），每个邮件可拥有专属 personalizations、动态模板参数及附件。相比 SMTP（通常仅 2–5 封/秒）或逐条 REST 请求（网络开销大、连接频繁、易触发限流），批量 API 显著降低 HTTP 开销与认证成本。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
以下为 Go 中调用批量 API 的核心示例（使用官方 sendgrid-go SDK）：
package main
import (
"github.com/sendgrid/sendgrid-go"
"github.com/sendgrid/sendgrid-go/helpers/mail"
)
func sendBatchEmails() error {
sg := sendgrid.NewSendClient("YOUR_SENDGRID_API_KEY")
// 构建批量邮件列表（最多 1000 封）
var emails []*mail.SGMailV3
for i := 0; i <h3>⚠️ 关键注意事项</h3>
- 速率限制与并发策略：SendGrid 对 /v3/mail/send 的默认限频为 1200 请求/分钟（即最多每分钟 120 万封邮件，按每批 1000 封计）。建议采用固定大小批次（如 500–1000 封/批）+ 限速协程池（如每秒 15–20 批），避免 429 错误。
- 错误处理必须精细化：批量响应返回 202 Accepted 仅表示“已接收”，不保证投递成功。需结合 Webhook 或事件 webhook（Event Webhook）监听 delivered, bounced, spamreport 等状态，并对失败邮件做重试或隔离。
- 避免模板硬编码：优先使用 SendGrid 动态模板（Dynamic Templates）而非内联 HTML，便于 A/B 测试、版本管理与渲染解耦；渲染服务只需注入 dynamic_template_data。
- TLS 与连接复用：Go 客户端务必启用 HTTP 连接池（http.Transport 配置 MaxIdleConnsPerHost ≥ 100），并确保 TLS 会话复用，减少握手延迟。
✅ 性能对比小结
| 方式 | 吞吐量（估算） | 延迟特征 | 运维复杂度 | 推荐指数 |
|---|---|---|---|---|
| SMTP | 2–5 封/秒 | 高（DNS/握手/HELO） | 中 | ⭐⭐ |
| 单封 REST | ~50–100 封/秒 | 高（每封独立 HTTP） | 低 | ⭐⭐⭐ |
| 批量 REST（500+/批） | 10,000–15,000 封/分钟 | 低（批处理+复用） | 中高 | ⭐⭐⭐⭐⭐ |
综上，对于日均数十万级已渲染邮件的投递任务，坚定采用 SendGrid v3 批量 REST API，并配合合理的批处理大小、并发控制与事件反馈机制，是兼顾性能、可靠性与可维护性的最优路径。
