Go无法直接编译eBPF代码，因内核verifier严格限制（禁循环、栈限512B、无浮点等），且go compiler不识别eBPF section语法；必须用Clang编译C程序，再由Go加载解析。
不能直接在 Go 里写 eBPF 检测逻辑，必须用 Clang 编译 C 风格的 eBPF 程序（如 tracepoint 或 kprobe），再由 Go 用户态程序加载、attach 并消费 map 数据；否则会遇到 verifier 拒绝、符号未定义或权限错误。
为什么 go build 无法编译含 eBPF 代码的 .go 文件
eBPF 程序受内核校验器严格约束：禁止循环、栈大小固定（512 字节）、无浮点、无任意函数调用。Go 编译器生成的指令远超这些限制，go tool compile 甚至不识别 __attribute__((section("tracepoint/syscalls/sys_enter_openat"))) 这类语法。
常见错误现象：
- 把
SEC("kprobe/do_sys_open") int bpf_prog(...) { ... }直接塞进main.go→undefined reference to 'bpf_prog' - 运行
go run main.go启动含 eBPF section 的文件 → 编译失败，提示 “syntax error: unexpected @” 或 “unknown directive”
正确构建链路：Clang 编译 + Go 加载 + 安全事件提取
安全事件（如敏感文件访问、异常 exec、socket 绑定）需靠 eBPF 程序捕获上下文，再经 map 传给 Go。关键步骤如下：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
clang -O2 -target bpf -c openat.c -o openat.o编译 C 源码（禁用-O3，避免 verifier 拒绝） - 确保内核开启
CONFIG_BPF_SYSCALL=y和CONFIG_DEBUG_INFO_BTF=y（后者对解析struct task_struct字段偏移至关重要） - Go 侧使用
libbpf-go（非cilium/ebpf）加载：它支持 BTF 自动推导字段，避免因内核版本差异导致panic: invalid field offset - attach 到
tracepoint/syscalls/sys_enter_openat后，从perf_event_array读 ringbuf，而非轮询普通 map —— 否则高并发下丢事件
Go 读取事件时最容易忽略的三个坑
即使 eBPF 程序成功加载并触发，Go 侧仍可能漏掉事件或 panic，原因多在数据搬运环节：
-
Map.Lookup()返回指针指向内核内存，若未立即拷贝或并发修改，下次读就是脏数据；应改用Map.LookupAndDeleteBatch()或PerfEventArray.Read() - 手写 Go struct 匹配内核 event 结构？大概率错：字段顺序、padding、
__u64vsuint64必须完全一致；推荐用btfgen自动生成，而非手动定义 - 没过滤 UID/NAMESPACE 上下文：容器中
syscall.Getuid()返回 0，需结合/proc/[pid]/status解析Uid:行，并检查nsproxy判断是否在 host netns 中
真正难的不是加载一个 kprobe，而是让事件解析在不同内核版本、不同容器运行时（containerd vs CRI-O）、不同命名空间嵌套深度下都稳定输出字段语义正确的记录——BTF 和 libbpf-go 的类型自动适配是绕不开的一环。
