-go run -race 可检测并发读写竞态，精准定位非同步读写/写写冲突，但仅限本地测试与CI；pprof可查goroutine阻塞、锁竞争及block热点；dlv用于深入调试多goroutine执行顺序。
用 go run -race 抓住竞态源头
并发读写冲突不会报错，但会让程序行为飘忽不定——数值偶尔错、结构体字段被覆盖、日志顺序混乱。这类问题必须靠 -race 检测器显式触发，它会在运行时插桩监控所有内存访问，一旦发现两个 goroutine 对同一地址有非同步的读+写或写+写，立刻打印精确位置。
常见漏网场景包括：map 并发读写（哪怕只是 for range + 单个写）、sync.Pool 复用对象后未清空字段、struct 中混用 atomic.StoreInt64 和普通赋值。注意：-race 会显著拖慢程序、翻倍内存占用，**只用于本地测试和 CI 阶段，生产环境严禁常驻启用**。
看 /debug/pprof/goroutine?debug=2 找卡死现场
当接口延迟飙升但 CPU 不高，大概率是 goroutine 堆积在 channel 或锁上。接入 net/http/pprof 后访问该地址，输出的是所有 goroutine 的完整调用栈。重点关注那些停在 chan receive、sync.(*Mutex).Lock 或 runtime.gopark 的堆栈——它们不是崩溃了，而是被阻塞了。
容易踩的坑：http.ListenAndServe 忘记启动；容器内没暴露 6060 端口；防火墙拦截；或者用了 pprof 但没加 _ "net/http/pprof" 导入导致路由未注册。
立即学习“go语言免费学习笔记（深入）”；
查 pprof/block 和 pprof/mutex 定位锁竞争热点
/debug/pprof/block 显示 goroutine 因同步原语（channel、mutex、semaphore）而阻塞的总时长，能帮你判断是否真被锁拖住；/debug/pprof/mutex 则列出锁竞争最激烈的前几处，直接定位到哪行 mu.Lock() 被争抢最多。
典型信号包括：Goroutine 阻塞时间 > 100ms、Mutex 加锁等待次数持续上升、CPU 利用率高位震荡但吞吐不增。此时要检查临界区是否包含网络调用、数据库查询或复杂计算——这些不该放在锁里。
用 dlv debug 进入 goroutine 内部看执行顺序
当竞态逻辑嵌套深、日志看不出谁先谁后，就得用调试器。比如一个 channel 发送端和接收端都在等对方，光看堆栈分不清因果。用 dlv debug main.go 启动后，可用 goroutines 查所有协程，goroutine <id> frames</id> 切进去看当前栈帧，再配合 step 或 next 单步验证执行流。
关键点在于：不要只看单个 goroutine，要对比多个相关 goroutine 的状态；注意 channel 是否已关闭或缓冲满；确认 context 是否已超时但未被检查。
-race 但没跑够压力，漏掉了偶发路径。 
