Go并发错误需用-race检测竞态、pprof查goroutine泄漏、channel+context兜住错误、警惕死锁提示并规范channel与锁使用。
Go并发错误往往不报panic，也不直接崩溃，而是表现为超时、数据错乱、goroutine堆积或静默失败。定位这类问题，关键不是猜，而是用对工具、看准线索、守住模式。
用-race快速揪出数据竞争
竞态条件是最隐蔽也最常发生的并发错误。只要涉及多个goroutine读写同一变量（比如全局计数器、map、结构体字段），且没加锁或没用原子操作，就极可能中招。
- 运行时加 -race：go run -race main.go，它会实时标记哪两个goroutine、在哪个文件哪一行、对哪个变量发生了读-写/写-写冲突
- CI中强制开启：避免只在本地测试漏掉竞态，尤其要覆盖高并发压测场景
- 注意：-race会显著拖慢程序，仅用于开发和测试，不可上线启用
查goroutine堆积用pprof
程序变慢、内存上涨、CPU空转？很可能是goroutine卡死或泄漏。pprof能让你“看见”所有goroutine在干什么。
- 启动调试端口：import _ "net/http/pprof"，再起一个goroutine监听:6060
- 访问 /debug/pprof/goroutine?debug=2：列出全部goroutine堆栈，重点关注停在 chan send、chan receive、sync.(*Mutex).Lock 的那些
- 配合 /debug/pprof/goroutine?debug=1 看总数趋势，若持续增长，基本可断定有泄漏
错误不能丢——用channel+context兜住goroutine失败
goroutine里发生的错误无法return给调用方，忽略它等于埋雷。必须显式传递、统一收集、及时响应。
- 每个worker goroutine出错时，往同一个errCh chan error发错误（记得缓冲，防阻塞）
- 主协程用select监听errCh和ctx.Done()，实现“任一出错即终止”或“超时即放弃”
- 推荐用errgroup.Group替代手写逻辑，它自动聚合第一个错误、支持上下文取消、语义更清晰
死锁就看运行时提示和channel配对
Go会在所有goroutine都阻塞时自动报错：fatal error: all goroutines are asleep - deadlock! 这是明确信号，别跳过。
- 检查无缓冲channel：发送前必须确保有接收者在等，反之亦然；宁可用带缓冲channel或select default兜底
- range channel别忘close：接收方range会永远等待，除非发送方显式close
- 锁顺序要一致：多个mutex嵌套时，所有goroutine必须按相同顺序获取，否则极易循环等待
基本上就这些。不复杂，但容易忽略。
