eBPF本身不提供零拷贝，仅能前置干预数据包；真正的零拷贝需AF_XDP配合双进程协作，Go侧通过UMEM与ring buffer通信，且须验证内核配置与权限。
eBPF 本身不提供零拷贝传输能力，它只是让 Go 能“靠近”零拷贝路径
eBPF 程序不能替代 Go 做 socket 收发，也不能直接把包“塞进” Go 的 net.Conn。它的作用是前置干预：在数据刚进网卡时就过滤、重定向或打标记，把真正要处理的包“精简后送出去”，从而减少后续用户态的无效搬运。真正的零拷贝发生在 AF_XDP socket 层，而 Go 只能通过它收发帧——前提是 eBPF 已完成初始筛选。
AF_XDP 是 Go 实现零拷贝的唯一可行路径，但必须双进程协作
Go 进程无法加载或运行 XDP 程序，也不能直接操作 UMEM 或 ring buffer。你必须拆成两部分：
- eBPF 侧：用 Clang 编译
xdp_prog.c→ 生成prog.o→ attach 到网卡（需CAP_NET_ADMIN） - Go 侧：用
cilium/ebpf加载并管理程序；再用AF_XDPsocket（通过golang.org/x/sys/unix或封装库如xdp-go）分配 UMEM、轮询 RX/TX ring buffer - 二者靠共享内存页（UMEM）通信，不是靠函数调用——Go 不会“调用”eBPF，只是读它预填好的帧
常见错误：试图在 Go 里写 SEC("xdp") void xdp_func() → 编译失败；或以为 io.Copy 跟 XDP 有关联 → 完全无关，io.Copy 走的是完整协议栈，此时 XDP 早被绕过了。
Ring Buffer 是最常用且安全的 eBPF ↔ Go 数据通道
如果你不需要极致吞吐（比如只是采集连接状态、统计包数），用 bpf_ringbuf_output() + Go 侧 ebpf.Map.ReadFrom() 更简单稳定：
立即学习“go语言免费学习笔记（深入）”；
- eBPF 程序用
bpf_ringbuf_output()把结构体（如struct event { u32 pid; u16 port; };）推入 ringbuf - Go 用
coll.Maps["events"].ReadFrom()持续读取，无需 memcpy，内核自动更新 consumer offset - 相比 perf buffer，ringbuf 零拷贝、无丢包、支持多消费者，且
cilium/ebpf对其封装成熟 - 注意：ringbuf 传的是结构体快照，不是原始包数据；若需完整包，仍得走 AF_XDP
权限、内核配置和调试点必须提前验证
很多“不工作”问题根本不出现在 Go 代码里，而是卡在加载或运行前：
- 检查
/proc/sys/net/core/bpf_jit_enable是否为1（JIT 提升性能，非必需但强烈建议） - 确认内核开启 XDP 支持：
cat /boot/config-$(uname -r) | grep -i xdp应含CONFIG_XDP_SOCKETS=y -
ebpf.Program.Load()失败时，错误信息里常带校验器拒绝原因，例如"invalid func call"（用了不支持的 helper）、"stack limit exceeded"（局部变量超 512 字节） - AF_XDP socket 绑定失败？大概率是网卡不支持 XDP（
ip link show dev eth0中无XDP字样）或 UMEM page size 不匹配（必须是 hugepage 或 4KB 对齐）
真零拷贝不是加个 flag 就行的事——它要求整个数据流从 DMA 开始就被设计成页共享，任何环节引入 copy（比如 Go 里 bytes.Buffer.Write() 接收 ringbuf 数据）都会让前面所有努力归零。
