libbpf-go加载eBPF程序需先用clang编译为.o文件，再指定ProgramTypeXDP或ProgramTypeClassifier加载并attach至XDP/TC钩子；XDP性能高但限制多，TC更灵活可访问socket上下文；数据推荐用ring_buffer零拷贝接收，须正确初始化、注册回调并轮询。
用 libbpf-go 加载 eBPF 程序并 attach 到 XDP 或 TC 钩子
Go 本身不原生支持 eBPF，必须依赖 C 库封装。目前最稳定、生产可用的是 libbpf-go（aquasecurity/libbpf-go），它直接绑定 libbpf v1.0+，避免了 CGO 调用旧版 libbpf-cgo 的内存泄漏和信号中断问题。
关键点：eBPF 程序不能“被调用”，而是被加载到内核、attach 到网络钩子（如 XDP、TC_INGRESS），再通过 perf_event_array 或 ring_buffer 向用户态投递数据包元信息或 payload。
实操建议：
- 确保内核 >= 5.10（XDP 支持更完整），且已启用
CONFIG_BPF_SYSCALL=y、CONFIG_XDP_SOCKETS=y（若用 XDP_SOCK） -
libbpf-go不自动编译 eBPF C 代码，需先用clang+llc编译为.o文件：clang -g -O2 -target bpf -c xdp_prog.c -o xdp_prog.o
- Go 侧加载时必须指定程序类型：
ProgramTypeXDP或ProgramTypeClassifier，否则LoadAndAssign会返回invalid argument - attach 前需检查网卡是否支持 XDP（
ip link show dev eth0看是否有xdp字段）；TC 方式则无需硬件支持，但延迟略高
从 ring_buffer 读取捕获的数据包
libbpf-go 推荐用 ring_buffer（而非老式 perf_event_array）接收数据，因为它的内存零拷贝、无锁、支持 per-CPU，吞吐更高，且 Go 绑定层做了自动事件分发。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：程序启动后没收到任何包，但 bpf_trace_printk 显示程序已运行——大概率是 ring buffer 未正确初始化或事件回调没注册。
实操建议：
- 定义与 eBPF 端一致的 Go 结构体，并用
binary.Read解析（注意字节序，x86_64 是小端） - 调用
rb, err := libbpf.NewRingBuffer("events", obj.RingBufs["events"], handler)，其中"events"是 eBPF C 中struct { __uint(type, BPF_MAP_TYPE_RINGBUF); }的 map 名 -
handler函数里别做阻塞操作（如 HTTP 请求），否则 ring buffer 溢出丢包；建议只存入 channel 或无锁队列 - 务必在
defer rb.Close()前调用rb.Poll(300)启动轮询，否则不会触发回调
用 XDP 或 TC？选型取决于你要捕获什么
XDP 在驱动层处理，能拿到原始帧（含 L2 头），性能极高（百万级 pps），但限制多：不能改包、不能访问 socket 上下文、部分网卡驱动不支持 offload 模式。
TC（Traffic Control）在内核协议栈更上层（ingress/egress hook），可访问 skb 元数据（如 skb->sk）、支持重定向和修改，适合做基于 socket 的连接追踪或应用层采样。
实操建议：
- 抓全量原始包、做 DDoS 检测 → 优先 XDP；需要知道是哪个进程发的包 → 必须 TC +
skb->sk查找 - XDP 程序中禁止调用
bpf_skb_load_bytes读取超过 256 字节（除非开启XDP_FLAG_SKB_MODE），否则可能 crash - TC 程序 attach 时要指定
Parent: netlink.NewTCHandle(0xffff, 0)（对应 clsact qdisc），否则Invalid argument - 两者都可通过
bpf_map_lookup_elem共享状态 map，比如计数器或白名单 IP
调试失败时先看这三处
eBPF 加载失败往往不是 Go 代码问题，而是环境或 eBPF C 逻辑导致。90% 的报错停在这三步。
实操建议：
- 加载失败报
permission denied→ 检查是否以 root 运行，或是否启用了unprivileged_bpf_disabled=0（sysctl kernel.unprivileged_bpf_disabled） - attach 失败报
operation not supported→ 用bpftool prog list确认程序已加载且 type 匹配；再用ip link show dev eth0确认网卡支持对应模式（XDP/TC） - ring buffer 无数据但 eBPF 程序计数器在涨 → 用
bpftool map dump id $MAP_ID看 event map 是否有值；或临时加bpf_printk("hit: %d", skb->len)确认路径可达
真正难的不是写几行 Go，而是理解 eBPF 程序生命周期、内核钩子语义、以及数据如何跨特权边界安全传递。一旦 map 类型配错、attach 点选错、或 ring buffer 回调 panic，整个管道就静默失效。
