goroutine泄漏是最隐蔽危险的并发错误，因channel未关闭、锁未释放或select缺少default/case导致goroutine阻塞等待而无法回收。
goroutine 泄漏：忘记回收或阻塞等待
最隐蔽也最危险的并发错误。goroutine 启动后若因 channel 未关闭、锁未释放、或 select 中没有 default 或 case ，就可能永远卡住，持续占用内存和 goroutine 调度资源。
- 常见现象：
runtime.ReadMemStats显示MNumGoroutine持续上涨，pprof 查看/debug/pprof/goroutine?debug=2发现大量chan receive或semacquire - 典型场景：HTTP handler 中启动 goroutine 处理耗时任务，但没绑定
context.Context；或循环中无条件go fn()却未控制并发数 - 修复关键：所有长期运行的 goroutine 必须监听
ctx.Done()；用sync.WaitGroup或errgroup.Group等待完成；避免在循环里裸写go func() { ... }()
竞态条件（data race）：共享变量未同步访问
Go 编译器不禁止多 goroutine 直接读写同一变量，但结果不可预测。即使看起来“偶尔出错”，也是严重 bug —— go run -race 是唯一可靠检测手段。
- 典型错误：结构体字段被多个 goroutine 同时读写，却没加
sync.Mutex或用atomic；map在并发下读写（哪怕只读+写） - 容易忽略点：闭包中引用的局部变量（如
for i := range xs { go func() { use(i) }() }）导致所有 goroutine 共享同一个i变量 - 正确写法：
for i := range xs { i := i // 创建新变量 go func() { use(i) }() }或go func(i int) { use(i) }(i)
channel 使用不当：死锁、panic 和逻辑错位
channel 不是万能队列，它的阻塞语义极易引发死锁，而 close 和 nil channel 的行为又常被误用。
- 死锁高频场景：
unbuffered channel的发送和接收不在同一时刻发生；或所有 goroutine 都在等某个 channel，但没人发/收 - panic 风险：
close(nil)panic；向已关闭的 channel 发送数据 panic；从已关闭且无数据的 channel 接收返回零值（不 panic），但容易掩盖逻辑错误 - 建议实践：
send-only/recv-onlychannel 类型明确职责；用select+default避免无限阻塞；关闭 channel 应由 sender 单方面负责，receiver 不应 close
sync.Mutex 误用：忘记加锁、重复加锁、锁粒度过大
sync.Mutex 是最常用同步原语，但它的生命周期和作用域稍有偏差，就会导致竞态或性能瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：把 mutex 当作函数局部变量（每次调用都新建），完全起不到保护作用；或在方法中对指针 receiver 加锁，但调用方传的是值拷贝
- 锁粒度陷阱：整个函数体用一个 mutex 包裹，把本可并行的操作串行化；尤其在 HTTP handler 中，会显著降低 QPS
- 安全习惯：mutex 字段必须导出为
mu sync.Mutex（小写首字母），且结构体必须以指针形式传递；读多写少场景优先考虑sync.RWMutex；避免在锁内做 I/O、网络调用或长耗时计算
