必须用C/Clang写eBPF程序并编译为.o，Go仅负责加载与管理；cilium/ebpf因不读BTF、硬编码字段偏移，在5.15+内核中读tracepoint参数常为空或乱码，应改用libbpf-go实现BTF动态解析。
不能直接用 Go 写并运行 eBPF 程序，必须分离：C/Clang 编写内核态逻辑 → 编译为 bpf.o → Go 用户态程序加载、attach、读 map。这是唯一能落地的路径，所有绕过它的尝试都会在 Load() 或运行时静默失败。
为什么 cilium/ebpf 在 tracepoint 场景下大概率读不到参数
它不读 BTF，靠硬编码字段偏移解析 struct trace_event_raw_sys_enter。而内核 5.15+ 把 args[0] 改成了 args[0].args[0]，结构体填充也变了。结果就是：bpf_probe_read_user_str 传入错误地址，返回 -EFAULT，但被静默忽略，你收到的 filename 字段永远为空或乱码。
解决方法只有两个：
- 降级到 5.10 以下内核（不现实）
- 换用
libbpf-go，它会从内核 BTF 自动推导字段名和偏移，ctx.args[0]这种写法才真正可靠 - 确保内核开启
CONFIG_DEBUG_INFO_BTF=y，且安装对应kernel-debuginfo包
如何让 Go 正确读取 eBPF map 中的监控数据
map 是唯一通信通道，但直接 Map.Lookup() 极易出错：字段对齐错位、并发读写冲突、大 map 遍历卡死 goroutine。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
- 结构体定义必须严格匹配内核侧：字段顺序、
__u64对应uint64，不能用int64；建议用btfgen自动生成 Go struct，别手写 - 高频场景下，避免 JSON 序列化或深拷贝；改用
unsafe.Slice+ 预分配缓冲区解析原始字节 - perf event map 必须用
PerfEventArray.Read()循环消费 ringbuf，不能调Lookup - 批量读 map 优先用
LookupAndDeleteBatch，减少 syscall 次数
tracepoint 和 kprobe 的选择不是“哪个更强大”，而是“哪个不会拖垮性能”
tracepoint 是内核预埋的静态钩子，开销在纳秒级，参数语义明确（比如 sys_enter_read 的 fd 和 count 可直接用）；kprobe 是动态插桩，每次命中都要走 trap 处理，开销高一个数量级，且参数需手动解析寄存器或栈，极易因内联、ABI 变更失效。
选错的后果很直接：
- 用 kprobe hook
tcp_sendmsg做网络监控 → QPS 下降 30%+ - 用 tracepoint hook
syscalls/sys_enter_openat→ 几乎无感，且ctx->args[0]指向文件路径，稳定可读 - uprobe 追踪 Go 函数时，
%ax不一定还是第一个参数 —— Go 1.17+ 寄存器 ABI 下，若函数被内联或加了-gcflags="all=-l"，uprobe 就根本挂不上
BTF 不是可选项，是生产环境的底线。没有它，你写的每个字段读取都像在掷骰子；有了它，libbpf-go 才能把 ctx.args[0] 真正映射到内存里那个字节上。这点最容易被跳过，但一旦跳过，后面所有调试都在对抗幻觉。
