goroutine 启动后立即退出是因为主 goroutine 结束导致程序终止；应使用 sync.WaitGroup 显式等待，避免循环变量复用、慎用 time.Sleep，并对共享数据加锁或用 channel 同步。
goroutine 启动后立刻退出？检查是否缺少同步等待
Go 程启动后若主 goroutine（main）结束，整个程序立即退出，所有子 goroutine 被强制终止——这不是“泄漏”，是设计行为。常见错误是写完 go doSomething() 就直接 return 或函数结束。
- 用
sync.WaitGroup显式等待：在启动前wg.Add(1)，每个 goroutine 结束前调用wg.Done()，主 goroutine 调用wg.Wait()阻塞直到全部完成 - 避免在循环中复用同一变量地址传参，例如
for _, v := range items { go func() { fmt.Println(v) }() }会导致所有 goroutine 打印最后一个v值；应改为go func(val string) { fmt.Println(val) }(v) -
time.Sleep不是可靠同步手段，仅用于调试；它无法保证 goroutine 已执行完，且掩盖了真正的并发控制缺失
多个 goroutine 读写共享数据时 panic 或结果错乱？必须加锁或换通道
Go 不禁止裸共享内存，但 int、map、slice 等类型在并发读写时未加保护会触发 fatal error: concurrent map iteration and map write 或静默数据损坏。
- 简单计数场景优先用
sync/atomic：如atomic.AddInt64(&counter, 1)，比sync.Mutex开销更低且无阻塞 - 结构体字段多或逻辑复杂时用
sync.Mutex或sync.RWMutex：注意锁的粒度——不要把 HTTP 处理逻辑整个包进mu.Lock()，只包裹真正共享访问的几行 - 天然适合通信场景（如生产者-消费者）用
chan：发送方ch ，接收方item := ，底层自动同步，无需显式锁
goroutine 泄漏怎么发现和定位？关注 channel 阻塞与 WaitGroup 忘记 Done
goroutine 泄漏典型表现是程序常驻内存持续增长，pprof 查看 /debug/pprof/goroutine?debug=2 返回数百上千个处于 chan receive 或 semacquire 状态的 goroutine。
- 向已关闭的 channel 发送数据会 panic，但从已关闭 channel 接收会得到零值 +
ok==false；务必确保 sender 关闭 channel 前，所有 receiver 已退出或通过其他信号（如done chan struct{}）被通知 -
WaitGroup忘记Done()是最常见泄漏原因：尤其在 error 分支、defer 前 return、或 panic 恢复后遗漏调用；建议用defer wg.Done()放在 goroutine 函数开头 - 使用
context.Context控制生命周期：启动 goroutine 时传入ctx，在 select 中监听ctx.Done()，收到信号后清理资源并退出
func worker(ctx context.Context, jobs <-chan int, results chan<- int) {
for {
select {
case job, ok := <-jobs:
if !ok {
return
}
results <- job * 2
case <-ctx.Done():
return
}
}
}要不要用 errgroup 或 semaphore 控制 goroutine 并发数？看场景再决定
无节制启动 goroutine（如为 10 万条记录起 10 万个 goroutine）会耗尽内存或文件描述符，但过度抽象（如强行套用第三方库）反而增加理解成本。
立即学习“go语言免费学习笔记（深入）”；
- 需要限制并发请求数（如批量调 API）：用
semaphore（基于 channel 的计数信号量）比自己写sync.WaitGroup+sync.Mutex更清晰；标准库暂无，可用golang.org/x/sync/semaphore - 需统一收集错误且任意一个出错就取消其余任务：用
errgroup.Group，它内置context取消传播和错误聚合，比手写更健壮 - 简单并行任务（如并发读几个文件）且数量可控（sync.WaitGroup + channel 就够用，不必引入额外依赖
实际并发控制中最容易被忽略的，是忘记给 goroutine 设置退出路径——无论是 channel 关闭、context 取消，还是明确的 done 信号，只要没有出口，它就永远卡在那儿。
