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 的行为又常被误用。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 死锁高频场景：unbuffered channel 的发送和接收不在同一时刻发生；或所有 goroutine 都在等某个 channel，但没人发/收
• panic 风险：close(nil) panic；向已关闭的 channel 发送数据 panic；从已关闭且无数据的 channel 接收返回零值（不 panic），但容易掩盖逻辑错误
• 建议实践：send-only/recv-only channel 类型明确职责；用 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、网络调用或长耗时计算

实际项目里，最难 debug 的往往不是语法错误，而是那些“看起来运行正常、压测才暴露、上线后偶发崩溃”的并发问题。别依赖直觉判断“这里不会并发”，只要变量跨 goroutine 流转，就必须显式同步 —— 这不是啰嗦，是 Go 并发模型的基本契约。