goroutine泄漏是最常见的并发隐患，表现为启动后未回收或阻塞等待，持续占用资源；sync.WaitGroup需Add在goroutine启动前、Done配对且用defer；channel须由唯一发送方关闭；共享变量读写均需mutex保护。
goroutine 泄漏：忘记回收或阻塞等待
启动 goroutine 后不关心它的生命周期，是最常见的并发隐患。只要 go func() {...}() 执行了，它就独立运行，哪怕外层函数已返回，goroutine 仍可能卡在 channel 接收、锁等待、或无限循环里，持续占用内存和 goroutine 栈。
典型场景包括：
- 向无缓冲 channel 发送数据，但没人接收 ——
ch <- val永久阻塞 - 用
select等待多个 channel，却漏写default或case <-done:做退出控制 - 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()。
立即学习“go语言免费学习笔记（深入）”；
正确做法：
-
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 从明显变成隐蔽。
