直接用bpf.NewProgram加载eBPF程序会失败，因其仅支持已验证的字节码，而tracepoint类程序必须由clang编译C源码生成.o文件，依赖内核头定义的寄存器布局和系统调用号映射，且需设为BPF_PROG_TYPE_TRACEPOINT或RAW_TRACEPOINT类型，并启用CONFIG_BPF_SYSCALL=y和CONFIG_TRACING=y。
为什么直接用 bpf.NewProgram 加载 eBPF 程序会失败？
Go 中用 ebpf 库（如 github.com/cilium/ebpf）加载 eBPF 程序时，bpf.NewProgram 仅支持加载已验证通过的 BPF 字节码，但系统调用监控必须用 tracepoint 或 raw_tracepoint 类型程序，这类程序无法靠纯 Go 构造——它们依赖内核头文件定义的 struct pt_regs 布局和系统调用号映射，且需在内核态解析寄存器上下文。
常见错误现象：operation not supported 或 invalid argument，本质是程序类型不匹配或缺少 BPF_F_TRUSTED_HELPER 权限。
- 必须用
clang编译 C 源码生成.o文件，不能手写字节码 - 程序类型必须设为
BPF_PROG_TYPE_TRACEPOINT或BPF_PROG_TYPE_RAW_TRACEPOINT（后者更稳定，支持所有 sys_enter/sys_exit） - 加载前需确保内核配置启用
CONFIG_BPF_SYSCALL=y和CONFIG_TRACING=y
如何用 libbpf-go 绑定 sys_enter tracepoint？
libbpf-go 是目前最稳妥的选择，它封装了 libbpf 的加载逻辑，能自动处理 tracepoint 路径拼接、perf event ring buffer 初始化等细节。关键不是“怎么写 Go”，而是“怎么让 Go 正确挂载 C 编写的 eBPF 程序”。
使用场景：监控指定进程的 openat、read 等调用，或全局统计各系统调用频次。
立即学习“go语言免费学习笔记（深入）”；
- C 端需在
SEC("raw_tracepoint/sys_enter")函数中读取ctx->args[1]获取系统调用号（__NR_openat等），再用bpf_get_current_pid_tgid()过滤目标进程 - Go 端用
obj := ebpf.NewMap(&ebpf.MapSpec{Type: ebpf.RingBuf, ...})创建 ringbuf 接收事件，不用 perf event（libbpf-go 对 perf 支持较弱） - 加载后必须调用
link, _ := link.AttachRawTracepoint(link.RawTracepointOptions{Name: "sys_enter"})，注意Name是 tracepoint 名称，不是函数名
libbpf-go 读 ringbuf 时为什么卡住或丢数据？
ringbuf 是无锁、内存映射的环形缓冲区，但 Go 侧消费不当会导致数据覆盖或阻塞。这不是 Go 本身问题，而是对 ringbuf 生产/消费模型理解偏差。
性能影响：ringbuf 比 perf event 快 3–5 倍，但要求消费者持续轮询；若处理慢，新事件会覆盖未读旧事件（ringbuf 默认不阻塞生产者）。
- 必须用
reader := obj.RingbufReader()后立即启动 goroutine 循环调用reader.Read()，不能只读一次 - 每次
Read()返回的是原始字节，需按 C 端struct syscall_event手动解包（用binary.Read或unsafe.Slice），字段顺序必须与 C 端struct一致 - 若发现丢数据，调大 ringbuf 大小：C 端
MAP_DEF("maps/events", .type = BPF_MAP_TYPE_RINGBUF, .max_entries = 4096 * 1024)
如何过滤特定 PID 并避免被 execve 刷新掉？
eBPF 程序挂载后不会随用户进程 execve 自动更新 PID 映射，所以仅靠 bpf_get_current_pid_tgid() 取到的是当前线程的 pid ，而子进程 fork 后 PID 变化，但 eBPF 代码本身仍运行在内核上下文中，无需重载。
容易踩的坑：在 Go 里用 os.Getpid() 获取的 PID 是 Go 进程自身 PID，不能直接传给 eBPF map 作过滤键——eBPF 中的 PID 是内核视图下的 thread group ID（即主线程 PID），且需右移 32 位。
- C 端过滤逻辑应写成：
if ((ctx->args[0] >> 32) != target_pid) return 0;（args[0]是sys_enter的第一个参数，即 PID/TGID） - Go 侧向 eBPF map 写入 target_pid 时，要写入
uint32(os.Getpid())，不是int或uint64 - 若需监控多个 PID，用
BPF_MAP_TYPE_HASH存 PID 集合，C 端用bpf_map_lookup_elem()查表，比硬编码判断更灵活
实际跑通的关键不在 Go 语法，而在 C 端结构体对齐、tracepoint 名称拼写、ringbuf 消费节奏这三处。任何一处错，都会表现为“没输出”或“输出乱码”。
