strace 在 go 程序中无法捕获真实 i/o 耗时，因 go 运行时用 epoll_wait 封装非阻塞 i/o，syscall 与业务逻辑脱钩；tracepoint 通过内核原生 sys_enter/exit 事件捕获所有系统调用，配合 btf 自动解析参数、时间戳计算及上下文串联，才能精准归因耗时。
strace 在 Go 程序里基本抓不到真实耗时，别白费劲了——Go 运行时用 epoll_wait 封装 I/O，syscall 和业务逻辑完全脱钩。
为什么 tracepoint 比 strace 更靠谱
Go 的 net/http、os.Open 等操作不直接触发 read/write 系统调用，而是走 runtime 的非阻塞轮询（如 epoll_wait），strace -e trace=read,write 只能看到零星调用，且无法关联到 goroutine。
-
tracepoint/syscalls/sys_enter_read和sys_exit_read是内核原生事件，无论 Go 是否封装，只要最终进入 syscall，它就捕获 - libbpf-go 能自动从 BTF 推导参数布局，比如
ctx->args[0]（fd）、ctx->args[2]（count），不用硬编码偏移 - 配合
bpf_ktime_get_ns()记录进出时间戳，就能算出真实阻塞耗时
用 libbpf-go 抓 read/write 耗时的最小闭环
重点不是“怎么写 eBPF”，而是“怎么让数据可读、可对齐、不崩溃”。以下步骤缺一不可：
- 内核必须开启
CONFIG_DEBUG_INFO_BTF=y，否则 libbpf-go 无法解析struct trace_event_raw_sys_enter字段 - eBPF C 侧用
SEC("tracepoint/syscalls/sys_enter_read")+SEC("tracepoint/syscalls/sys_exit_read")成对埋点，用 map 存 PID-TGID → start_ns - Go 侧用
Map.LookupAndDeleteBatch批量取键值，避免单次 syscall 开销；结构体字段名（如fd、ret）必须和 BTF 中一致，不能手写args[0] - 别在 eBPF 里做字符串拷贝或复杂计算——
bpf_probe_read_user_str易失败，bpf_printk仅限调试
容易被忽略的三个坑
很多项目跑起来没报错，但数据全是 0 或乱码，问题往往卡在这三处：
- Go 编译时加了
-gcflags="all=-l"（禁用内联），导致 uprobe 失效；但 tracepoint 不受影响，所以优先选 tracepoint 而非 uprobe - 容器中运行需
--cap-add=SYS_ADMIN或--privileged，否则failed to load object: permission denied - 用
clang -target bpf -O2编译，别用-O3—— verifier 对循环/跳转容忍度低，加载失败报invalid argument却不提示具体原因
真正难的不是挂上 eBPF，而是把一次 HTTP handler 的延迟，精准归因到某次 read 耗时上。这需要在 Go 业务层打 trace ID，并通过 perf event map 把 ID 和系统调用事件绑定——BTF 解析只是起点，上下文串联才是关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
