ebpf不能直接分析go函数调用热点，因其无法穿透go runtime的goroutine多路复用模型，仅能观测系统调用、内核函数等内核态行为，而go函数如http.servehttp在用户态执行且受编译优化（如内联）、符号缺失等限制，uprobe稳定性差、统计意义弱。
Go 程序本身不能直接运行 eBPF 程序来定位自身性能瓶颈 —— eBPF 是内核态观测技术，它看的是系统行为（调度、syscall、I/O、网络栈），不是 Go 运行时内部细节（goroutine 调度、GC、channel 阻塞）。想用 eBPF 查 Go 服务的问题，得明确：它补的是 pprof 的盲区，不是替代品。
为什么不能用 eBPF 直接分析 Go 函数调用热点
eBPF 无法穿透 Go runtime 的 goroutine 多路复用模型。它看到的往往是 sys_write、epoll_wait、clone 这类系统调用，或内核函数如 tcp_v4_do_rcv；而 http.ServeHTTP 或 json.Marshal 这类 Go 函数在用户态执行，eBPF 默认不可见。除非你用 uprobe 手动挂到特定二进制符号上，但稳定性差、需符号表、易受内联/编译优化影响。
- eBPF 的 kprobe/uprobe 不保证函数入口/出口能稳定捕获 —— Go 编译器可能内联、重排、甚至把小函数完全展开
- uprobe 需要目标函数地址可解析，而 Go 二进制默认不保留 DWARF 符号（尤其加了
-ldflags="-s -w"） - 即使挂上了，采样频率和 Go 的 goroutine 快速切换也不匹配，统计意义弱
什么场景下 eBPF 对 Go 服务真正有用
当 pprof 显示大量 runtime.futex、runtime.mcall、epoll_wait，但业务函数几乎不出现时，说明瓶颈在系统层 —— 这才是 eBPF 的发力点。
-
查 syscall 卡顿：用
execsnoop看 Go 进程是否频繁fork/exec外部命令；用biolatency看磁盘 I/O 延迟是否突增，对应 Go 的os.ReadFile变慢 -
查网络收发异常：用
tcptop或tcpsubnet发现某连接持续重传、零窗口，说明 Go 的net.Conn.Write在等 TCP ACK，而非代码逻辑问题 -
查上下文切换风暴：用
runqlat发现 runqueue 延迟飙升，结合profile（eBPF 版）确认是大量 goroutine 抢占 CPU，指向 Go 的select或 channel 使用不当 -
查锁竞争源头：用
bashreadline或自定义 kprobe 挂在mutex_lock，看哪个进程/线程持锁最久 —— 如果是 Go 进程，再回头用pprof/goroutine?debug=2搜semacquire
如何让 eBPF 和 pprof 协同工作
单独用任何一方都容易误判。典型协作路径是：pprof 定位“现象”，eBPF 验证“根因”，再回 pprof 确认修复效果。
- pprof 发现 CPU profile 里
runtime.mallocgc占比高 → 先用 eBPF 的memleak（bpftrace 版）确认是否真有内核内存泄漏，排除 slab 压力干扰 - pprof 的
/goroutine?debug=2显示大量chan receive卡在某 client.go:72 → 用 eBPF 的opensnoop看该 goroutine 是否在等某个文件就绪，或是tcplife看对应连接是否已断但 Go 没关 conn - trace 工具显示 GC STW 时间长 → 用 eBPF 的
hardirqs看是否硬中断激增（如网卡收包风暴），导致 Go scheduler 被挤占
最常被忽略的一点：eBPF 脚本输出的时间戳默认是纳秒级，而 Go 的 time.Now() 在某些内核版本下可能被 eBPF probe 干扰（尤其是使用 kprobe:do_syscall_64 时），导致压测中时间测量失真 —— 如果你发现加了 eBPF 监控后 pprof 的耗时统计变乱，先停掉所有 syscall 级 probes。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
