不能用 go 直接写、编译、运行 ebpf 程序；必须用 c（或 rust）编写逻辑，经 clang 编译为 bpf elf 对象文件，再由 go 用户态程序（推荐 libbpf-go）加载并 attach，因 go 编译器无法生成验证器接受的字节码。
不能用 Go 直接写、编译、运行 eBPF 程序——这是最常踩的坑。所有“在 main.go 里定义 SEC("tracepoint/syscalls/sys_enter_openat")”的尝试都会失败，因为 Go 编译器不生成校验器可接受的字节码，内核会直接拒绝加载。
必须用 Clang/LLVM 编译 eBPF C 代码为 .o 文件
eBPF 程序逻辑必须用 C（或 Rust）编写，通过 clang -target bpf 编译成 ELF 格式的对象文件（如 probe.o），再由 Go 用户态程序加载。Go 本身只负责解析 ELF、创建 map、attach 到 tracepoint/kprobe/uprobe 等钩子。
- 错误做法：
go build含__attribute__((section("tracepoint"))) void sys_enter_openat()的 .go 文件 → 链接失败或undefined reference - 正确流程：写
probe.c→clang -O2 -g -target bpf -c probe.c -o probe.o→ Go 调用cilium/ebpf或libbpf-go加载probe.o - 注意：禁用
-O3，内核 verifier 对复杂控制流容忍度低；保留-g便于调试和 BTF 生成
生产环境优先选 libbpf-go 而非 cilium/ebpf
做安全防护探针（比如监控 execve、openat、connect 等敏感调用）时，libbpf-go 是更稳的选择，尤其在 5.15+ 内核上。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
-
cilium/ebpf不读取 BTF，靠硬编码字段偏移解析struct trace_event_raw_sys_enter，不同内核版本字段顺序/填充变化会导致读到空值或乱码，且静默失败 -
libbpf-go自动从 BTF 推导参数布局，例如ctx.args[0]在新内核中自动映射到真实filename地址，无需手动维护 - 前提：系统需开启
CONFIG_DEBUG_INFO_BTF=y，并安装对应内核头文件（如linux-headers-$(uname -r)）
安全探针的关键 hook 点与注意事项
轻量级防护探针不拦截、只检测，核心是选对 hook 点并避免误报：
-
tracepoint/syscalls/sys_enter_execve：捕获进程执行，但注意ctx->args[0]是filename用户态地址，需用bpf_probe_read_user_str()安全读取，否则可能返回-EFAULT -
kprobe/do_filp_open或uprobe到 Go 运行时函数（如runtime.open）：比sys_enter_openat更早，可绕过部分 syscall wrapper 绕过，但 uprobe 插入点需确认未被内联（加-gcflags="all=-l"编译） -
tracepoint/syscalls/sys_enter_connect：监控出向连接，注意 IPv6 地址结构体长度与 IPv4 不同，需分支处理 - 所有读用户内存操作必须带
if (ret 检查，eBPF 不允许 panic 或异常退出
Go 用户态逻辑要聚焦策略与上报，别碰 map 直读
安全探针的 Go 部分职责很明确：加载程序、读 ringbuf、匹配规则、上报告警。不要试图在 Go 里轮询 map 或做复杂匹配。
- 用
ringbuf（非perf_events）接收事件：零拷贝、低延迟、支持 per-CPU，cilium/ebpf和libbpf-go都原生支持 - 规则匹配放用户态：例如 “非白名单路径的 execve”、“目标端口为 22 且进程名含 curl” —— 这类逻辑在 Go 里写更灵活、易测试、可热更新
- 上报建议走本地 Unix socket 或 gRPC，避免依赖外部服务导致探针阻塞；紧急事件可用
printk+dmesg快速验证 - 权限：必须以
root运行，且需cap_sys_admin或cap_bpf（5.8+ 内核）
BTF 支持不是可选项，是安全探针在多内核版本下稳定运行的底线。没 BTF，你写的 bpf_probe_read_user_str(&e->filename, ...) 在一台机器上正常，在另一台就永远为空——这种问题不会报错，只会让你花几天时间怀疑人生。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
