本文深入剖析 Go 程序中在 goroutine 内调用 smtp.SendMail 时出现“挂起不返回”的根本原因，指出罪魁祸首并非 SMTP 协议本身，而是主 goroutine 的空忙等待（for {}）导致调度器失效，并提供符合 Go 并发模型的最佳实践解决方案。
本文深入剖析 go 程序中在 goroutine 内调用 `smtp.sendmail` 时出现“挂起不返回”的根本原因，指出罪魁祸首并非 smtp 协议本身，而是主 goroutine 的空忙等待（`for {}`）导致调度器失效，并提供符合 go 并发模型的最佳实践解决方案。
你遇到的现象——go SendEmail("TEST") 启动后无响应，而加一句同步调用 SendEmail("TEST") 反而让两个邮件都成功发送——看似诡异，实则精准暴露了 Go 调度器（Goroutine Scheduler）与操作系统线程（OS Thread）协同工作的关键机制。
核心问题在于：for {} 是一个无休止的 CPU 忙循环（busy loop），它会持续占用当前 OS 线程，且因内部无函数调用、无栈检查、无内存分配，Go 运行时无法插入调度点（preemption point），导致调度器完全丧失对主 goroutine 的控制权。结果是：其他 goroutine 永远得不到执行机会。
这与 smtp.SendMail 本身无关——它是一个阻塞式 I/O 操作，依赖网络往返，需要时间完成。但问题在于：你的主 goroutine 把唯一可用的 OS 线程（尤其当 GOMAXPROCS=1 时）死锁住了，调度器连尝试运行 SendEmail goroutine 的机会都没有。
而当你添加 SendEmail("TEST") 同步调用时，该函数内部包含网络 I/O、系统调用（如 connect、write）及多次函数调用，这些操作天然触发调度器介入，使 go SendEmail("TEST") 得以被调度执行——这纯属“副作用”，绝非可靠行为。
✅ 正确做法：永远避免 for {}，改用 select {} 实现无消耗的永久阻塞。
select {} 不占用 CPU，它会立即将当前 goroutine 置为 waiting 状态，并主动让出 OS 线程，调度器可自由调度其他就绪 goroutine：
func main() {
go SendEmail("TEST")
// ✅ 安全、高效、符合 Go 语义的等待方式
select {} // 永久阻塞，零 CPU 开销
}⚠️ 补充注意事项：
- 不要依赖 GOMAXPROCS > 1 来掩盖 for {} 问题：即使多线程存在，忙循环仍会严重浪费资源、干扰调度公平性，且在单核环境或容器限制下必然失败。
-
生产环境需更健壮的退出机制：select {} 适合简化示例，实际服务应监听 os.Signal（如 SIGINT）或使用 sync.WaitGroup 管理 goroutine 生命周期：
func main() { var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() SendEmail("TEST") }() // 等待所有任务完成（或接收中断信号） wg.Wait() } - SMTP 安全提醒：示例中硬编码密码和明文传输存在严重安全隐患。生产代码应使用环境变量管理凭据，并启用 TLS（推荐 smtp.Dial + Auth + StartTLS 流程），或直接使用支持 OAuth2 的库（如 github.com/jordan-wright/email）。
总结：Go 的并发模型建立在“协作式调度”基础上，for {} 违背了这一前提。理解调度器如何通过函数调用、系统调用、channel 操作等触发抢占，是编写可靠并发程序的基础。用 select {} 替代 for {}，不仅是修复 SMTP 阻塞的钥匙，更是践行 Go 并发哲学的第一课。
