默认 /debug/pprof/goroutine 不显示阻塞 goroutine，因其仅返回 running 或 runnable 状态的协程，而真正卡在 chan receive、semacquire 等阻塞点的 goroutine 已放弃 CPU 但未退出，需 ?debug=2 查全量栈。
热路径上的 goroutine 阻塞，90% 不是卡在业务逻辑，而是卡在 channel、mutex 或系统调用上——必须用 ?debug=2 看全量栈，否则你看到的只是“正在跑”的假象。
为什么 /debug/pprof/goroutine 默认不显示阻塞 goroutine
默认访问 /debug/pprof/goroutine 只返回状态为 running 或 runnable 的 goroutine，而真正泄漏或卡死的 goroutine 大量堆积在：chan receive、chan send、semacquire（锁）、select 或 sleep。它们已放弃 CPU，但没退出，也不会被默认接口列出。
- 现象：压测中
runtime.NumGoroutine()持续上涨，但top里只看到几十个活跃 goroutine - 原因：pprof 默认过滤掉了阻塞态，
?debug=1仅展示栈摘要，?debug=2才输出完整调用链和当前阻塞点 - 实操：用
curl "http://localhost:6060/debug/pprof/goroutine?debug=2" > goroutines.txt导出后 grepchan receive或semacquire
runtime.chansend1 和 runtime.chanrecv1 在 CPU profile 里高频出现意味着什么
这两个函数是 channel 阻塞的“守门人”：只要 goroutine 因缓冲满/空而挂起，必经此二函数。它们在 CPU profile 中占比高，不是因为耗 CPU，而是采样时大量 goroutine 正卡在 park 状态，反复被调度器采样到。
- 确认是否真阻塞：用
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/profile?seconds=30，点开runtime.chansend1→ 查看下游是否是gopark→park_m - 别只看占比：若
chansend1占比 >25%，且火焰图中它下方全是gopark，基本可断定是 channel 同步瓶颈 - 对比内存：同时跑
go tool pprof http://localhost:6060/debug/pprof/heap?allocs，看hchan结构体分配是否突增——说明 channel 创建过频或缓冲过大
如何判断 channel 是真瓶颈，还是伪热点
channel 阻塞本身合理，但不可预测的阻塞时间（比如延迟毛刺集中在 1.2ms / 2.4ms 档位）才是问题。关键看运行时积压程度和消费者行为，而非单纯“有没有阻塞”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 实时监控：在热路径加日志或指标，打印
len(ch)和cap(ch)的比值；长期 >0.9 表示背压已形成 - 异常信号：若
len(ch)突然归零又暴涨，大概率是消费者 panic 或 goroutine 泄漏导致 recvq 被清空重建 - 无缓冲 channel 要小心：
len(ch)永远是 0，但它仍可能永久阻塞；此时必须结合?debug=2栈信息 +/debug/pprof/block查阻塞源头 - 别盲目扩 buffer：buffer=1024 只是把阻塞延后，不能解决消费者处理变慢的本质问题；优先考虑
select { case ch 做非阻塞保护
热路径里容易被忽略的隐式阻塞点
除了 channel 和 mutex，热路径上几个轻量操作在高并发下会变成串行瓶颈，且不易被第一眼识别。
-
time.Now()：看似无害，但在 10k+ QPS 下触发频繁系统调用，pprof 中表现为runtime.nanotime或clock_gettime占比升高 - 同步日志：
log.Printf或未配置异步 writer 的 zap/slog，内部用 mutex 串行写，sync.(*Mutex).Lock会出现在 block profile 顶部 - HTTP client 超时缺失：热路径中发起无超时的
http.DefaultClient.Do，goroutine 会长期卡在net.(*conn).read，状态显示为IO wait - 未设
GOMAXPROCS的 128 核机器：goroutine 调度器争用加剧，runtime.mcall和runtime.gosched_m在 CPU profile 中异常突出，需配合runtime/trace确认调度延迟
真正难排查的不是“哪里卡住了”，而是“为什么卡住后不报错也不退出”——goroutine 泄漏往往藏在 defer 未执行、context 未 cancel、或 select 缺少 default 分支这种细微处。每次加 go，都要问一句：它怎么结束？
