Go并发三大问题：死锁（channel收发不匹配、mutex重复锁定）、竞态（共享变量未同步）、Goroutine泄漏（协程永久阻塞）。需用context、锁、race检测等工具预防。
Go 并发问题最常卡在三类现象上：程序停住不动（死锁）、结果每次都不一样（竞态）、服务跑着跑着就变慢甚至 OOM（Goroutine 泄漏）。它们不总在本地复现，但线上一出就是大问题。关键不是“能不能写出来”，而是“写完后是否真能安全退出、正确同步、及时释放”。
死锁：不是卡在代码里，是卡在逻辑配对上
Go 的死锁提示很明确：fatal error: all goroutines are asleep - deadlock!。但它不告诉你哪条 channel 没人接、哪把锁被谁锁死了。核心原因就两个：
- 无缓冲 channel 的收发没“碰上”——一方发，另一方还没启或已退出；一方收，发送端根本没动或已关闭
- sync.Mutex 被同个 goroutine 重复 Lock，且没 unlock（比如 defer 写错位置、递归调用持锁）
- select 等待多个 channel，所有 case 都阻塞，又没 default 或 ctx.Done() 保底，整个 goroutine 就挂在那里
修复思路不是加更多锁，而是检查“谁负责发、谁负责收、谁负责关、谁负责解锁”。例如启动 goroutine 做接收前，确保发送逻辑已就绪；用 ctx.Done() 替代纯 channel 等待；给 mutex 加锁范围严格限定在临界区，defer mu.Unlock() 必须紧跟 mu.Lock() 后。
竞态条件：共享变量没保护，读写就乱套
多个 goroutine 同时读写一个变量，且至少有一个写操作，行为就不可预测。编译器不会报错，go run -race 也未必每次触发，但压测时极易暴露。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 全局变量、结构体字段、闭包捕获的循环变量（如
for i := range items { go func(){ println(i) }() }总输出最后一个值）都算共享数据 - map 和 slice 本身非并发安全，即使只读写各自索引，也要加锁或改用 sync.Map
- 别依赖“我只读它，应该没事”——只要有人写，所有读就必须同步
标准解法是显式同步：读写共用变量必须用 sync.Mutex 或 sync.RWMutex 包裹；高频读低频写的场景可考虑 sync.Once 或原子操作 atomic. 系列。
Goroutine 泄漏：看不见的资源黑洞
泄漏的 goroutine 不会 panic，也不会立刻报错，只是永远卡在某处：等一个永远不会来的 channel 消息、拿不到锁、或没监听 ctx.Done() 就进了无限循环。几小时后可能吃光内存。
- HTTP handler 中启 goroutine 处理异步任务，但没绑定 request context，请求取消后协程还在跑
- for-select 循环里只等 channel，channel 关了却没检查
ok，导致继续空转 - sync.WaitGroup 的
Add()写在 goroutine 启动后，或Done()因 panic 没执行到
验证方式很直接：访问 /debug/pprof/goroutine?debug=2 查看堆栈，重点关注长期停在 chan receive、select 或 semacquire 的协程；上线前用 runtime.NumGoroutine() 打点监控，看数量是否随请求稳定或持续上涨。
调试和预防要靠工具+习惯
单靠肉眼很难发现这些问题。日常开发中应形成固定动作：
- 所有 goroutine 启动前，必配
context.Context，退出路径必走select { case <-ctx.Done(): return } - 所有 channel 操作，发送方负责关闭，接收方必用
val, ok := <-ch判断状态 - 所有共享变量读写，先问一句：“有没有其他 goroutine 在碰它？” 没有保护就加锁，不确定就加
- 本地测试跑
go test -race，CI 流水线集成 pprof 快照比对
不复杂但容易忽略——真正让 Go 并发稳健的，从来不是语法多炫，而是每一步是否留了退出口、是否守住了边界、是否经得起压测那一锤。
