Goroutine泄漏是隐蔽的内存杀手，因协程永不退出导致内存耗尽；正确做法是始终用context.Context配合select监听ctx.Done()实现优雅退出。
Go 并发编程最常踩的坑不是“不会写”，而是“看似能跑，实则埋雷”——比如 Goroutine 永不退出、channel 关了又发、for 循环里闭包捕获错变量、context 被忽略导致请求结束后协程还在狂转。这些问题在线上压测或流量突增时才爆发，调试成本极高。
Goroutine 泄漏：看不见的内存杀手
泄漏的 Goroutine 不会自动回收，哪怕只多开 100 个长期阻塞的协程，几小时后就可能吃光内存。典型场景是：启动了协程却没给它“退出开关”。
- 错误写法：
go func() { for { doWork() time.Sleep(1 * time.Second) } }()—— 没检查ctx.Done()，也无外部通知机制 - 正确做法：始终用
context.Context控制生命周期go func(ctx context.Context) { for { select { case <-ctx.Done(): return // 优雅退出 default: doWork() time.Sleep(1 * time.Second) } } }(parentCtx) - 验证手段：访问
http://localhost:6060/debug/pprof/goroutine?debug=1查看堆栈，重点关注长时间阻塞在chan receive或select的协程
Channel 死锁与关闭 panic
channel 是 Go 并发的枢纽，但也是死锁高发区。无缓冲 channel 要求收发双方“同时就绪”，稍有错位就卡死；而向已关闭的 channel 发送数据会直接 panic: send on closed channel。
- 常见死锁模式：
ch := make(chan int) ch <- 42 // 主 goroutine 阻塞在这里，没人接收
- 安全关闭原则：只由发送方关闭，且只关一次；接收方应通过
val, ok := 判断是否关闭 - 避免 panic 的写法：
if ch != nil { select { case ch <- data: default: // 缓冲满或已关闭，可丢弃或记录 } }
for 循环中启动 Goroutine 的变量陷阱
这是新手和老手都高频翻车的地方：循环变量在闭包中被“共享”，所有协程最终读到的是最后一次迭代的值。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 错误示例：
for i := 0; i < 3; i++ { go func() { fmt.Println(i) // 总是输出 3，不是 0/1/2 }() } time.Sleep(time.Millisecond) - 修复方式（任选其一）：
• 显式传参：go func(val int) { fmt.Println(val) }(i)
• 在循环内声明新变量：for i := 0; i < 3; i++ { i := i // 创建新绑定 go func() { fmt.Println(i) }() } - 更彻底的解法：用
range配合结构体指针或切片索引，避免依赖循环变量本身
竞态检测被跳过，上线才暴露
竞态条件（Data Race）不会编译报错，也不会每次必现，但它会让程序在高并发下随机返回错误结果或崩溃。最致命的是——很多人根本没开 -race 测过。
- 必须加在测试和 CI 中：
go test -race ./...
- 一旦报告竞态，不要绕过，要立刻定位：通常发生在多个 goroutine 同时读写同一个
int、map或结构体字段 - 修复优先级：能用
channel传递就不用共享内存；必须共享时，用sync.Mutex或sync/atomic，别手写“看起来线程安全”的逻辑
真正难的不是写出并发代码，而是写出“在 1000 QPS 下稳定跑一周还不泄露、不卡死、不返回脏数据”的并发代码。这些坑大多不靠直觉能避开，得靠工具（-race、pprof）、约定（谁关 channel、谁管 ctx）和持续验证来兜底。
