eBPF无法定位Go死锁，因其发生在用户态panic瞬间，内核无机会触发probe；它仅适用于排查“卡但不死”的阻塞，如futex、syscall或调度挂起等系统级阻塞。
eBPF 无法直接定位 Go 死锁
eBPF 不是死锁检测工具，它不能捕获 fatal error: all goroutines are asleep - deadlock! 这类 Go 运行时 panic。原因很直接：死锁发生时，整个程序瞬间终止，内核甚至来不及触发 eBPF 程序的执行上下文——probe 没机会被调用，tracepoint 不会触发，ringbuf 写不进去任何数据。你看到的 panic 日志、堆栈、goroutine 列表，全由 Go runtime 在用户态完成并输出，eBPF 根本插不上手。
那 eBPF 能做什么？定位“卡但不死”的阻塞
真正能用 eBPF 的场景，是服务没 panic、HTTP 请求变慢、goroutine 数持续上涨、CPU 却不高——也就是“活着但动不了”。这时 eBPF 可以穿透 Go runtime 抽象，观察真实系统行为：
- 用
tracepoint:syscalls:sys_enter_futex或uprobe:runtime.futex捕获 goroutine 因sync.Mutex或sync.WaitGroup阻塞在 futex 系统调用上的时刻，结合pid、stack_id定位具体 goroutine 和调用链 - 用
kprobe:do_syscall_64+uretprobe组合，测量某个 Go 函数（如net/http.(*conn).serve）从进入 syscall 到返回的耗时，判断是否卡在 read/write 上 - 用
tracepoint:sched:sched_blocked_reason获取进程/线程被调度器挂起的真实原因（比如IO、sleep、mutex），绕过 Go 的 M/P/G 调度抽象 - 对
net:net_dev_queue或tcp:tcp_sendmsg打点，确认阻塞是否来自网络栈而非 Go 代码本身
为什么 cilium/ebpf 在 Go 场景下容易失效
很多团队尝试用 cilium/ebpf 去读取 Go 函数参数或 goroutine 状态，结果拿到空值或乱码，不是代码写错了，而是底层机制不匹配：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
cilium/ebpf不依赖 BTF，靠硬编码字段偏移解析结构体；但 Go 1.17+ 启用寄存器 ABI 后，runtime.gopark的参数布局和内核 tracepoint 定义已不同步，ctx->args[0]可能根本不是你想找的 channel 指针 - uprobe 插入点若落在内联函数里（
-gcflags="-l"关闭内联后才稳定），%ax寄存器可能已被覆盖，读不到真实的g指针 - Go 的 goroutine 阻塞不一定会陷入 syscall——比如无缓冲 channel 阻塞是纯用户态自旋 +
runtime.gopark，不会触发futex_wait，eBPF 就看不到
该用什么工具组合才靠谱
别把 eBPF 当成万能锤。真实排查链路是分层的：
立即学习“go语言免费学习笔记（深入）”；
- 死锁刚发生？立刻看 panic 日志末尾的 goroutine 列表，盯住
maingoroutine卡在ch <- v、<-ch、wg.Wait()还是mu.Lock() - 服务卡住但没 panic？先跑
curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'，过滤chan receive和sync.(*Mutex).Lock - pprof 看不出头绪？上
go tool trace，回放 goroutine 状态变迁，找那个长期处于chan recv却没被唤醒的 goroutine - 以上都指向“系统层卡住”？再启动 eBPF，比如用
bpftrace -e 'tracepoint:sched:sched_blocked_reason /comm == "myapp"/ { printf("%s %s\n", comm, str(args->reason)); }'确认是不是真被内核级资源堵死了
最常被忽略的一点：eBPF 观察到的“阻塞”，90% 以上其实源于 Go 层设计缺陷——channel 收发不配对、WaitGroup 计数错、锁顺序混乱。工具只是镜子，照出问题，但解法永远在代码里。
