goroutine泄漏是最常见的并发隐患，表现为启动后未回收或阻塞等待，持续占用资源；sync.WaitGroup需Add在goroutine启动前、Done配对且用defer；channel须由唯一发送方关闭；共享变量读写均需mutex保护。

goroutine 泄漏：忘记回收或阻塞等待

启动 goroutine 后不关心它的生命周期，是最常见的并发隐患。只要 go func() {...}() 执行了，它就独立运行，哪怕外层函数已返回，goroutine 仍可能卡在 channel 接收、锁等待、或无限循环里，持续占用内存和 goroutine 栈。

典型场景包括：

• 向无缓冲 channel 发送数据，但没人接收 —— ch 永久阻塞
• 用 select 等待多个 channel，却漏写 default 或 case 做退出控制
• HTTP handler 中启 goroutine 处理耗时逻辑，但没绑定 request context，导致请求取消后 goroutine 仍在跑

验证是否泄漏：运行时调用 runtime.NumGoroutine() 观察数量是否随请求线性增长；或用 pprof 查看 /debug/pprof/goroutine?debug=2。

sync.WaitGroup 使用不当：Add 和 Done 不配对

sync.WaitGroup 不是“自动计数器”，Add() 必须在 goroutine 启动前调用，且不能在 goroutine 内部调用（除非加锁）。常见错误是把 wg.Add(1) 放在 go 语句之后，或在循环中重复调用 wg.Add() 却漏掉某些分支的 Done()。

正确做法：

• wg.Add(n) 在启动 n 个 goroutine 之前一次性调用（推荐），或确保每个 go 前调用一次 wg.Add(1)
• wg.Done() 必须在 goroutine 结束前执行，建议用 defer wg.Done() 避免遗漏
• 不要在 Wait() 之后再调用 Add()，会 panic：「WaitGroup is reused before previous Wait has returned」

for _, job := range jobs {
    wg.Add(1)
    go func(j string) {
        defer wg.Done()
        process(j)
    }(job)
}
wg.Wait()

channel 关闭时机错误：关闭未被发送方独占的 channel

channel 只能由发送方关闭，且只能关一次。多个 goroutine 同时向同一 channel 发送时，谁来关？如果任意一个发送方提前关闭，其他发送方再写就会 panic：「send on closed channel」。

安全模式只有一种：由明确的、唯一的发送协调者（比如主 goroutine 或专用 sender goroutine）负责关闭。常见反模式：

• 在每个 worker goroutine 里都写 close(ch)
• 用 range ch 循环读取，但没控制好发送端何时退出，导致读端永远等不到 close
• 关闭 channel 前没确保所有发送操作已完成（需配合 WaitGroup 或 context）

更稳妥的做法是用 context.Context 通知停止发送，让发送方自然退出，再由它关闭 channel。

共享变量竞态：以为 mutex 能包治百病

加了 sync.Mutex 就安全？不一定。常见疏漏：

• 只保护写，不保护读 —— 读操作同样需要加锁，否则可能读到中间态（如结构体字段部分更新）
• 锁粒度过粗：整个函数用一把锁，严重限制并发度；或过细：为每个字段建独立 mutex，增加维护成本和死锁风险
• 忘记在 defer 前加锁，或在错误路径上漏掉 Unlock()（推荐 mu.Lock(); defer mu.Unlock()）
• 用指针传入结构体但没同步访问其字段，比如 type Counter struct{ mu sync.Mutex; n int }，却直接读 c.n 而不加锁

用 go build -race 编译并运行，是发现竞态最直接的方式。它无法替代设计，但能暴露你忽略的读写交叉点。

并发不是加几个 go 就完事，而是围绕“谁在什么时候访问什么资源”做精确建模。初学者最容易低估的是状态可见性和生命周期耦合 —— 这两点不厘清，加再多锁、关再多 channel，都只是把 bug 从明显变成隐蔽。