Go仅负责加载配置与事件上报，eBPF才执行流量控制；eBPF程序必须用Clang编译为.o字节码，Go无法生成合法eBPF指令，因其运行时违反内核校验器对无环、无浮点、固定栈等约束。
go 本身不处理网络流量控制逻辑，ebpf 才是真正执行拦截、分类、重定向的组件；go 只负责加载、配置、读取和上报 —— 混淆这两层职责，90% 的失败都源于此。
为什么不能直接在 Go 里写 eBPF 过滤逻辑
eBPF 程序必须用 clang 编译为 BPF 字节码（.o 文件），Go 编译器无法生成合法 eBPF 指令。内核校验器会拒绝任何含浮点、循环、函数调用或越界访问的代码 —— 而 Go 的运行时机制天然违反这些约束。
常见错误现象：
-
undefined reference to 'xdp_prog'：把带SEC("xdp")的 C 函数塞进.go文件，go tool compile 直接报错 -
invalid func call或stack limit exceeded：用gcc编译 eBPF C 代码，或 C 里调了非 BPF 辅助函数（如printk） - eBPF 程序静默不触发：没 attach 到正确钩子，或 XDP 模式选错（
xdpdrvvsxdpoffload）
TC + cls_bpf 是最稳妥的流量控制入口
相比 XDP，tc（traffic control）层级更靠近协议栈，支持完整 IP/TCP 头解析，且兼容性更好（4.15+ 内核即支持）。尤其适合做基于五元组、TCP 标志位、TLS SNI 的策略分流。
实操要点：
- eBPF C 程序需挂载到
SEC("classifier")，返回BPF_OK/BPF_DROP/BPF_REDIRECT - Go 侧用
cilium/ebpf加载后，通过tc qdisc add dev eth0 clsact和tc filter add dev eth0 parent ffff: bpf da obj prog.o sec classifier完成 attach - 若需修改包内容（如 DNAT），必须用
tc+skb_store_bytes，XDP 不支持改包后转发到本机协议栈 - 注意：
cls_bpf默认只处理 ingress 流量；如需 egress 控制，得加egress子句并确保网卡驱动支持
Go 用户态如何实时响应流量事件
eBPF 程序不能直接发 HTTP 请求或写数据库，所有决策结果必须通过 BPF Map（如 BPF_MAP_TYPE_PERF_EVENT_ARRAY 或 BPF_MAP_TYPE_RINGBUF）传给 Go。
关键选择：
- 用
RingBuffer（推荐）：零拷贝、无丢包、Go 侧调rd.Read()即可获取结构化数据；需内核 5.8+ - 避免
PERF_EVENT_ARRAY：需 mmap + 轮询，易丢事件，且旧内核 perf buffer 有内存泄漏风险 - Map key 设计要贴合控制目标：例如按
src_ip + dst_port做 hash key，便于 Go 侧聚合统计连接数 - 不要在 eBPF 里做复杂计算：延迟统计用
bpf_ktime_get_ns()记时间戳，差值计算留给 Go
权限、调试与生产就绪检查项
本地跑通 ≠ 生产可用。以下三项漏一项，上线后大概率失联：
- 确认
/proc/sys/net/core/bpf_jit_enable为1（启用 JIT 提升 3–5 倍性能） - Go 二进制需
CAP_NET_ADMIN权限：sudo setcap cap_net_admin+ep ./controller，而非无脑sudo - 用
bpftool prog list验证程序已加载；用bpftool map dump id XXX查 Map 是否有数据写入；用tc filter show dev eth0确认 filter 已生效
最易被忽略的是：eBPF 程序一旦被校验器拒绝，LoadAndAssign() 就会返回具体错误字符串 —— 但很多人只打印 err != nil，没看错误内容，导致卡在“为什么我的程序不生效”上半天。
