dlv无法在高并发下捕获瞬时挂起的goroutine，需提前设防：禁用优化编译、加日志锚点、用pprof标记、手动读取waitreason字段定位阻塞原因。
不能靠“等它挂住再调试”——dlv 只能在暂停瞬间抓快照，而高并发下 goroutine 挂起往往转瞬即逝；必须提前设防、精准触发、快速定位。
dlv attach 进程后看不到挂起的 goroutine？先确认是否真挂住了
常见现象：服务响应变慢，top 显示 CPU 不高但请求堆积，dlv attach <pid></pid> 后执行 goroutines 却只看到几个 running 或 syscall 状态，没出现预期的 waiting / chan receive。
- 不是没挂，是挂得“太安静”：比如 goroutine 卡在
http.Serve的底层 accept loop 里，状态显示为syscall，实际已无法处理新连接 - 检查是否被调度器“藏起来”：用
goroutines -t 3（限制栈深度）避免刷屏，重点扫State列，semacquire、netpoll、epollwait都是网络阻塞典型信号 - 别信
go_goroutines指标：Prometheus 的go_goroutines只反映数量，不区分活跃/僵死；真正要查的是runtime.ReadMemStats中的MCacheInUse或 GC pause 时间突增——这往往比 goroutine 列表更早暴露调度异常
如何让挂起的网络协程在 dlv 里“显形”
默认情况下，dlv 对 http.Server 启动的 goroutine 缺乏上下文标记，goroutines 输出里全是 runtime.goexit 开头的匿名帧，ID 难对应、调用链难追溯。
- 启动时加编译标志：
go build -gcflags="all=-N -l" -o server ./cmd/server，禁用内联和优化，否则locals查不到 handler 参数、stack会跳过关键帧 - 给关键 handler 打日志锚点：在
http.HandleFunc内第一行加log.Printf("req %p started in goroutine %d", r, runtime.GoID())（Go 1.21+），运行时把 ID 和请求绑定，后续goroutine <id></id>切过去就能对上 - 用
pprof.Labels标记协程：在 handler 起始处套一层pprof.Do(ctx, pprof.Labels("handler", "login"), ...)，虽然 dlv 不直接显示 label，但配合runtime.Stack打印可辅助识别
看到 waiting 状态却找不到卡在哪？手动挖 waitreason
goroutines 显示某 goroutine ID 为 waiting，stack 却只到 runtime.gopark，没法知道它等 channel、锁还是 net.Conn ——因为真实原因存在 goroutine 结构体的 waitreason 字段，dlv 不自动解析。
- 切换过去：
goroutine <id></id> - 读取阻塞原因：
print (*runtime.g)(<id>).waitreason</id>（注意替换<id></id>为实际数字） - 常见输出含义：
"semacquire"= 锁竞争，"chan send"= channel 满了，"select"= select 阻塞无就绪 case，"netpoll"= 底层 socket 等待 IO - 若报
could not find symbol：说明 Delve 版本太低（需 ≥ v1.21）或目标二进制未带调试符号（重编译加-gcflags="all=-N -l"）
高频挂起场景：HTTP 长连接 + context.Done() 漏判
大量客户端保持长连接，服务端 goroutine 卡在 ，但 <code>goroutines 显示 waiting，waitreason 是 "chan receive"——表面看正常，实则因未检查 ctx.Err() 导致连接永不释放。
- 调试时立刻验证：
goroutine <id></id>→frame 2（跳到 handler 函数帧）→print ctx.Deadline和print ctx.Err，若Err已为context.Canceled却还在等 channel，就是逻辑缺陷 - 预防性写法：不用裸
，改用 <code>select { case ，或直接 <code>if ctx.Err() != nil { return } - 别依赖
http.TimeoutHandler：它只杀响应阶段，不干预 handler 内部的 long poll；真要控时，必须在 handler 里显式检查ctx
最易忽略的一点：dlv 的 goroutines 快照不包含刚创建、尚未调度的 goroutine——如果问题出在 go http.HandlerFunc 调用后立即 panic 或被调度器丢弃，它根本不会出现在列表里。这时候得靠 go run -gcflags="-l -N" -race 先过一遍竞态，再进 dlv。
