Go并发调试关键在于建立可观察、可中断、可回溯的习惯；-race能检测内存访问竞争但不反映业务逻辑问题，如counter递增竞态需结合代码逻辑分析。
Go 并发问题不是“看不出来”，而是不按套路出牌——fatal error: all goroutines are asleep - deadlock 这类 panic 一出现，程序就停住；WARNING: DATA RACE 却可能只在 CI 环境偶现；goroutine 数量从几百飙到上万，内存却没明显泄漏……关键不在“会不会写并发”，而在“有没有建立可观察、可中断、可回溯的调试习惯”。
用 go run -race 抓数据竞争，但别只信它报错的那一行
竞态检测器能发现变量被多个 goroutine 同时读写，但它插桩的是内存访问，不是业务逻辑。比如下面这段代码：
var counter int
func main() {
for i := 0; i < 10; i++ {
go func() {
counter++ // <- race detector 会在这里报 WARNING
}()
}
time.Sleep(time.Millisecond * 10)
fmt.Println(counter)
}它告诉你 counter++ 有竞争，但不会告诉你：为什么你没加 sync.WaitGroup 就直接退出了？为什么 10 个 goroutine 实际只执行了 3 个？
-
-race必须在开发和测试阶段常态化启用，CI 流水线里加go test -race ./...是底线 - 报错位置只是“症状”，要顺藤摸瓜查：这个变量是否被多个 goroutine 持有？有没有通过闭包意外捕获？
- 它对 map 并发读写、
time.Timer重复Reset、sync.Once多次调用等常见误用不敏感，得靠go vet和人工审查补位
死锁时第一眼要看 panic 输出里的 goroutine 调用栈，不是立刻改代码
当看到 fatal error: all goroutines are asleep - deadlock，Go 运行时默认就会打印所有 goroutine 的当前堆栈——这是最真实的一手现场证据，别跳过。
立即学习“go语言免费学习笔记（深入）”；
- 重点盯
main goroutine卡在哪：是卡在ch ？还是？或是mu.Lock()？ - 再扫其他 goroutine：是否全部卡在同一条 channel 操作上？比如都在等
或全堵在ch2 ？说明 channel 流向设计断了 - 如果日志被截断（尤其在容器或远程环境），加
GODEBUG=schedtrace=1000启动，每秒输出调度快照，看goroutines: N是否长期不变、状态是否全是waiting
典型陷阱：for range ch { ... } 却没人关 ch；两个 goroutine 分别向对方的 channel 发送，但彼此都还没启动接收逻辑。
查 goroutine 泄漏：用 /debug/pprof/goroutine?debug=2 看“活人名单”
程序跑着跑着变慢、内存缓慢上涨、ps -eLf | grep yourapp | wc -l 显示几千个线程？大概率是 goroutine 没退出。这时别猜，直接看运行时快照。
- 在代码里加
import _ "net/http/pprof"，再启一个后台服务：go http.ListenAndServe("localhost:6060", nil) - 请求
http://localhost:6060/debug/pprof/goroutine?debug=2，返回的是所有 goroutine 的完整调用栈，按状态分组（running、syscall、chan receive、select等） - 重点关注那些长期处于
chan receive或select的 goroutine：它们是不是在等一个永远不会来的信号？比如监听一个没人 close 的 channel，或等待一个超时未设的context.WithTimeout
注意：?debug=2 输出的是“此刻正在运行/阻塞”的 goroutine，不是历史记录。如果泄漏是间歇性的，得配合定时抓取或 Prometheus + go_goroutines 指标监控。
别让日志变成“谁干的？在哪干的？干了啥？”三连问
并发场景下，log.Printf("failed to process item") 这种日志等于没记——你根本不知道是哪个 goroutine、处理哪个任务、在哪个环节失败。
- 每个 goroutine 启动时，用
context.WithValue(ctx, key, traceID)注入唯一标识，日志中统一输出traceID - 避免用
runtime.Stack()解析 goroutine ID（性能差、不可靠），改用结构化日志库（如zap）的With方法传上下文字段 - 对关键通道操作加日志：发送前打
"sending to ch1: %v"，接收后打"received from ch1: %v"，配上traceID和时间戳，通信链路就串起来了
真正难的从来不是“怎么加日志”，而是“哪些地方必须加”。经验是：所有 channel 发送/接收点、所有 mu.Lock() / mu.Unlock()、所有 ctx.Done() 分支，一律打点。
