goroutine 是 Go 运行时调度的轻量执行单元，main 退出即强制终止所有 goroutine；需用 sync.WaitGroup 显式等待，Add 必须在 go 前调用，注意闭包变量陷阱。

goroutine 不是线程，也不是“后台任务”的代名词——它只是 Go 运行时调度的、可被快速创建和销毁的执行单元。你不需要“管理”它，但必须理解它何时会消失、何时会卡住、以及为什么 main 函数退出后其他 goroutine 全部被强制终止。

---

main 函数退出就 kill 所有 goroutine，没商量

这是最常被忽略的致命事实：main 函数返回那一刻，整个进程立即退出，所有正在运行的 goroutine 被硬杀，不执行 defer、不关闭 channel、不释放资源。

• 错误写法：go doWork(); time.Sleep(100 * time.Millisecond) —— 依赖时间猜测，不可靠
• 正确做法：用 sync.WaitGroup 显式等待完成
• 注意 WaitGroup.Add() 必须在 go 语句之前调用，否则可能漏计数
• 如果 goroutine 内部会 panic，defer wg.Done() 仍能保证计数正确（因为 defer 在 panic 前执行）

for 循环里启动 goroutine，闭包变量陷阱

下面这段代码几乎必出错：

for i := 0; i < 5; i++ {
    go func() {
        fmt.Println(i) // 总是打印 5，不是 0~4
    }()
}

原因：所有匿名函数共享同一个变量 i 的地址，循环结束时 i == 5，而 goroutine 启动是异步的，大概率读到最终值。

立即学习“go语言免费学习笔记（深入）”；

• 修复方式 1：传参捕获当前值：go func(val int) { fmt.Println(val) }(i)
• 修复方式 2：在循环内声明新变量：for i := 0; i
• Go 1.22+ 在 for range 中已默认按值绑定迭代变量，但普通 for 仍需手动处理

channel 关闭前必须确保没人再发

close(ch) 只能由发送方调用，且只能调用一次；向已关闭的 channel 发送数据会 panic：send on closed channel。

• 常见错误：多个 goroutine 同时往同一 channel 发，谁来 close？没人协调就容易 panic
• 推荐模式：用单个 sender（或用 sync.Once 包裹 close），receiver 用 for range 安全接收
• 不要靠 len(ch) == 0 判断是否该 close —— channel 长度不反映是否还有待发送数据
• 带缓冲 channel 的 len() 返回当前队列长度，cap() 返回容量，二者都与关闭状态无关

goroutine 泄漏：没接收的 send 或没发送的 recv

无缓冲 channel 的发送操作会阻塞，直到有 goroutine 接收；反之亦然。一旦逻辑出错，就卡死，goroutine 永远无法退出。

• 典型泄漏场景：ch := make(chan int); go func() { ch —— 没人接收，这个 goroutine 永远挂起
• 调试技巧：用 runtime.NumGoroutine() 日志观察数量是否持续增长
• 生产环境建议加超时：select { case ch
• 别依赖 time.After 单独做超时控制，要配合 select 使用

真正的难点不在语法，而在对“生命周期”的判断：哪个 goroutine 负责关 channel、谁等谁、谁该超时、谁负责清理。这些没法靠编译器检查，得靠设计时的明确约定。