go程序main函数返回即终止，不等待非主goroutine完成；这是设计使然，非bug。根本原因是运行时只等待main结束，忽略其他goroutine状态，导致defer不执行、输出丢失等现象。
Go程序不会等 goroutine 执行完才退出；main 函数一返回，整个进程立即终止，所有还在运行的非主 goroutine 被强制结束——这不是 bug，是设计使然。
为什么 goroutine 看似“没执行完”就消失了
根本原因在于 Go 运行时的退出逻辑：它只等待 main goroutine 结束，不关心其他 goroutine 是否仍在运行、是否阻塞在 channel 上、是否正在写文件或发 HTTP 请求。
- 常见错误现象：
go func() { time.Sleep(2 * time.Second); fmt.Println("done") }()很可能什么也不输出就退出 - 哪怕 goroutine 里有
defer，也不会执行——因为defer只在函数 return 前触发，而该 goroutine 根本没机会 return - 使用
log或fmt等带缓冲的输出时，还可能因缓冲未 flush 而丢失日志
WaitGroup 是最常用也最容易出错的同步方式
sync.WaitGroup 本质是计数器，靠 Add/Done 配对来跟踪 goroutine 生命周期，但它本身不提供任何调度或超时能力。
- 必须在
go语句前调用wg.Add(1)，否则Done可能导致 panic（计数器为负） - 闭包中传参要小心：循环变量
i在 goroutine 启动前可能已改变，应显式传入go func(id int) { ... }(i) -
wg.Wait()是阻塞调用，若某个 goroutine 永远不Done（比如死锁在 channel 上），主 goroutine 就永远卡住 - 它不处理错误传播，也不支持取消；想加超时得自己套
select+time.After
context.WithCancel 是生产环境推荐的协作式退出机制
当 goroutine 需要响应外部信号（如 HTTP 请求取消、服务 shutdown）、或内部存在多层调用栈时，context 比 WaitGroup 更健壮。
- 启动 goroutine 时传入
ctx，并在关键位置检查ctx.Err() != nil，及时退出 - 避免在 goroutine 内部直接调用
cancel()，除非你明确知道谁该负责取消——通常由父 goroutine 或顶层控制流决定 - 注意：
context不会自动关闭 channel 或释放文件句柄；它只是通知“该停了”，后续清理仍需手动做（比如defer关闭资源） - 和
WaitGroup并不互斥，常组合使用：wg.Add(1)+defer wg.Done()放在 goroutine 最外层，确保无论怎么退出都计入完成统计
runtime.Goexit 和 panic/recover 不该用于常规退出
runtime.Goexit() 能从任意栈深度退出当前 goroutine，但它绕过所有 defer，且无法被 recover 捕获；panic 则会触发整个 goroutine 的 defer 链，但属于异常路径，语义不清、难以测试。
- 它们适合极少数底层场景，比如实现自定义调度器或调试工具，而非业务逻辑中的“正常退出”
- 用
panic控制流程会导致堆栈污染，让错误日志难以区分真实 panic 和“假 panic” - 真正需要从深层函数退出时，应把
ctx一路透传下去，而不是靠Goexit或panic“破墙而出”
goroutine 的退出从来不是“要不要等”的问题，而是“如何定义完成”——是写完日志就算完，还是必须刷盘成功？是收到响应即可，还是得确认对方已落库？这些语义必须由代码显式表达，不能依赖运行时“帮忙等”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
