直接用 goroutine 发 net/smtp.SendMail 易丢邮件，因其每次调用都新建 TCP+TLS 连接，无连接复用与并发控制，易触发 SMTP 限流或耗尽系统资源。
为什么直接用 goroutine 发 net/smtp.SendMail 容易丢邮件
因为 net/smtp.SendMail 是同步阻塞调用，但并发不等于“无节制起 goroutine”。没做任何限制地为每封邮件起一个 goroutine，可能瞬间创建数百个连接，触发 SMTP 服务器限流（如 Gmail 返回 421 4.7.0 Try again later），或耗尽本地文件描述符，导致 dial tcp: lookup smtp.gmail.com: no such host 这类看似 DNS 失败、实为系统资源枯竭的错误。
- SMTP 连接建立开销大（TLS 握手 + 认证），频繁新建连接比复用慢得多
- 多数邮件服务商明确要求单 IP 单位时间发信上限（如 Outlook 限制 30 封/分钟）
-
net/smtp.SendMail内部不复用连接，每次调用都新建 TCP+TLS 连接
用 gomail 库 + 限速池替代裸 goroutine
gomail 封装了连接池和重试逻辑，比手写更可靠。关键不是“用不用 goroutine”，而是“如何控制并发节奏”。推荐用带缓冲的 channel 控制并发数，再配合 gomail.Dialer 复用连接。
- 不要用
go d.DialAndSend(m)直接并发——这仍会为每封邮件建新连接 - 用
gomail.NewDialer创建一个复用连接的*gomail.Dialer实例，全局复用 - 用
make(chan *gomail.Message, 10)做任务队列，另起固定数量 goroutine 消费（如 3–5 个） - 每条消息发送后检查
err：非空时记录日志，但别 panic —— 邮件失败应降级处理，不影响其他消息
func sendWithRateLimit(d *gomail.Dialer, msgs <-chan *gomail.Message, workers int) {
var wg sync.WaitGroup
for i := 0; i < workers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for m := range msgs {
if err := d.DialAndSend(m); err != nil {
log.Printf("send failed: %v", err)
// 可选：加入失败重试队列，或写入 DB 待人工处理
}
time.Sleep(2 * time.Second) // 强制限速，适配服务商策略
}
}()
}
wg.Wait()
}
net/smtp 手动复用连接的最小可行方案
如果因合规或调试需要绕过第三方库，必须自己管理连接。核心是：**连接复用 ≠ 全局单例**，而是在生命周期内复用同一 smtp.Client 实例，且确保并发安全。
-
smtp.Client本身不是 goroutine-safe 的，不能多个 goroutine 同时调用c.SendMail - 正确做法：每个 worker goroutine 自己
Connect→Auth→ 循环SendMail→Close，连接生命周期与 goroutine 对齐 - 避免在
defer c.Close()后继续用c，否则会 panic：smtp: invalid state: cannot send mail after close - TLS 配置必须显式传入
&tls.Config{ServerName: "smtp.gmail.com"}，否则某些证书校验失败
func worker(smtpAddr, user, pass string, jobs <-chan emailJob) {
c, err := smtp.Dial(smtpAddr)
if err != nil {
log.Printf("dial failed: %v", err)
return
}
defer c.Close()
if err = c.Auth(smtp.PlainAuth("", user, pass, "smtp.gmail.com")); err != nil {
log.Printf("auth failed: %v", err)
return
}
for job := range jobs {
if err = c.SendMail(job.from, job.to, job.msg); err != nil {
log.Printf("send job %s failed: %v", job.id, err)
}
}}
android rtsp流媒体播放介绍 中文WORD版
本文档主要讲述的是android rtsp流媒体播放介绍；实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
立即学习“go语言免费学习笔记（深入）”；
实际部署时最容易被忽略的三个点
本地跑通不等于线上可用。生产环境的 SMTP 并发常卡在这些细节：
- Gmail/Outlook 要求开启「App Password」而非账户密码，且需提前在账户设置里启用两步验证
- Docker 容器内默认 DNS 解析可能超时，需在
docker run加--dns 8.8.8.8或改用net=host - 云服务器（如 AWS EC2）默认屏蔽 25 端口，必须改用 587（STARTTLS）或 465（SSL），并确认防火墙放行出向连接
真正麻烦的从来不是并发模型，而是 SMTP 协议本身的约束和基础设施的隐性限制。先跑通单连接、单邮件，再加并发，最后调限速——跳过任一环，都会在凌晨三点收到告警。
