生产环境必须用libbpf-go而非cilium/ebpf做tracepoint追踪，因其依赖btf自动解析字段布局，避免5.15+内核中因硬编码偏移导致args[0]读取为空、乱码或attach静默失败。
直接用 cilium/ebpf 加载 tracepoint 会静默失败
你写好 SEC("tracepoint/syscalls/sys_enter_connect")，Go 侧调用 ebpf.LoadCollectionSpec 后程序看似跑起来了，但 ringbuf 里永远没数据——不是代码没触发，而是内核根本没把参数正确传进来。根本原因在于：cilium/ebpf 不读 BTF，它靠硬编码字段偏移解析 struct trace_event_raw_sys_enter，而这个结构体在 5.15+ 内核里字段顺序、填充、甚至字段名都变了（比如 args[0] 改成 args[0].val）。结果就是 bpf_probe_read_user_str(&e->filename, ...) 读到的是随机内存，返回 -EFAULT 还被静默忽略。
- 检查方法：运行时加
log.Printf("args[0] = %x", ctx.Args[0])，如果总是 0 或乱码，基本可判定是 BTF 解析失败 - 生产环境必须换
libbpf-go，它会在加载时自动从内核 BTF 中推导字段布局 - 确保内核开启
CONFIG_DEBUG_INFO_BTF=y，并安装对应版本的kernel-debuginfo包
追踪 TCP 连接事件必须绕过 conntrack 的盲区
别依赖 conntrack -L 判断连接是否建立成功。conntrack 只记录进入 Netfilter 钩子的包，而 SYN 被 iptables -j DROP、或走 ip_forward 未启用 conntrack、或被 eBPF TC 程序短路时，它就完全看不见。你要抓的是“连接尝试”本身，不是“连接状态”。
- 推荐钩子点：
tracepoint/sock/inet_sock_set_state，它在struct sock状态变更时触发，覆盖SYN_SENT→ESTABLISHED→CLOSE全路径 - 关键字段要从
struct sock里读：sk->__sk_common.skc_daddr（目的 IP）、sk->__sk_common.skc_dport（目的端口），不能只信ctx->args - 读取时必须用
bpf_probe_read_kernel，且对齐处理：IPv4 地址需bpf_ntohl()转换，端口需bpf_ntohs()
Go 用户态收不到 ringbuf 数据？先查权限和缓冲区配置
libbpf-go 的 ringbuf.NewReader 返回 nil 或一直阻塞，常见原因不是代码写错，而是内核侧没真正提交数据。这通常卡在两个地方：权限不足导致 attach 失败，或 ringbuf 太小被快速填满后丢弃新事件。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- attach 权限：
tracepoint需CAP_SYS_ADMIN，普通用户运行需提前执行sudo setcap cap_sys_admin+ep ./your-binary - ringbuf 大小：默认
256 * 1024字节不够高并发场景，建议设为4 * 1024 * 1024（4MB），并在 map 定义里显式声明__uint(max_entries, 4 * 1024 * 1024) - 验证是否真正触发：在 eBPF C 代码里加
bpf_printk("connect: %pI4:%d → %pI4:%d", &saddr, sport, &daddr, dport)，然后sudo cat /sys/kernel/debug/tracing/trace_pipe查看输出
自定义协议解析必须用 bpf_core_read，别用 bpf_probe_read_kernel
你想从 struct sock 里读 sk->sk_pacing_rate 或 sk->sk_rtt，但这些字段在不同内核版本中偏移不同，硬编码偏移或用 bpf_probe_read_kernel 直接读会崩溃或读错。BTF 是唯一可靠方案。
- 必须用
#include <bpf></bpf>，然后写u32 rtt = BPF_CORE_READ(sk, sk_rtt); -
BPF_CORE_READ在编译期通过 BTF 自动计算字段路径，不依赖运行时偏移 - Clang 编译时加
-g和-D__KERNEL__，否则 BTF 信息无法嵌入 ELF - Go 侧无需任何额外操作，
libbpf-go会自动识别并应用 BTF 重写
真实网络协议事件的复杂性不在代码行数，而在内核结构体随版本漂移、ringbuf 丢数据无声无息、以及 tracepoint 参数解析这种“看起来在跑，其实没干活”的静默失效。最容易被忽略的，是以为自己在读 ctx->args[0]，实际上读的是内核早已废弃的字段名。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
