因为open系统调用在现代内核中被重定向为openat(AT_FDCWD, ...)，且实际路径分散于open、openat、openat2等多个系统调用入口，单纯hook sys_open不可靠；bpf.OpenAt是eBPF程序类型而非Go函数，需attach到tracepoint:syscalls:sys_enter_openat等稳定钩子，并安全读取用户态filename指针。
为什么 bpf.OpenAt 不能直接捕获所有 open 系统调用
因为内核中文件打开行为分散在多个系统调用路径里：open、openat、openat2，甚至部分 execve 也会触发内部 open。单纯 hook sys_open 在现代内核（5.10+）中已被移除或不可靠，而 bpf.OpenAt 是 eBPF 程序类型，不是 Go 函数——你没法“调用”它，只能用它来 attach 到对应内核 tracepoint 或 kprobe。
实际做法是：用 libbpfgo 或 ebpf-go 加载一个 eBPF 程序，attach 到 sys_enter_openat tracepoint（最稳定），再从 ctx->args[0] 和 ctx->args[1] 提取 dfd 和 filename。
- 优先用
tracepoint:syscalls:sys_enter_openat，而非 kprobe onsys_openat：避免符号变化和 CONFIG_KPROBE_EVENTS=y 依赖 -
open系统调用在 x86_64 上实际被重定向为openat(AT_FDCWD, ...)，所以 hookopenat能覆盖绝大多数场景 - 注意：
filename是用户态地址，必须用bpf_probe_read_user安全读取，否则程序校验失败
Go 中加载并 attach eBPF 程序的最小可行步骤
用 libbpfgo（推荐）比原生 ebpf-go 更贴近内核语义，对 tracepoint 支持更稳。关键不是“写 Go 代码监控”，而是让 Go 正确加载、attach 并读取 perf event ring buffer。
- 编译 eBPF C 代码时必须指定
-target bpf，且 include#include "vmlinux.h"（用bpftool btf dump file /sys/kernel/btf/vmlinux format c生成） - Go 侧用
module := libbpfgo.NewModuleFromFile("trace_open.bpf.o")加载，别漏掉.o后缀 - attach 前必须先
module.BPFLoadObject()，否则GetProgram返回 nil - perf event buffer 需手动
perfBuf, _ := module.InitPerfBuf("events", handler, lostHandler, 64)，其中"events"是 BPF 程序里bpf_perf_event_output(ctx, &events, ...)的 map 名 - 启动监听前记得
perfBuf.Start()，否则没数据；退出前调perfBuf.Stop()防资源泄漏
读取 filename 字符串时常见的 panic 和静默失败
eBPF 程序里传给 userspace 的 filename 是指针，Go 侧收到的是原始字节数组，不是 null-terminated string。如果直接 string(buf[:])，可能包含中间 \x00 或越界读到脏内存，导致日志错乱或 panic。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 在 eBPF C 里限制读取长度：
bpf_probe_read_user_str(filename, sizeof(filename), (void*)filename_ptr);（自动截断并补 \x00） - Go 侧解析时用
bytes.IndexByte(data, 0)找第一个 \x00，再string(data[:idx])，不要硬切固定长度 - 如果
idx == -1（没找到 \x00），说明读取不完整或出错，应丢弃该条记录，避免后续处理崩溃 - 别忽略
errno字段：eBPF 里ret = bpf_get_current_pid_tgid()是安全的，但bpf_probe_read_user_str失败会返回负值，需在 C 里判断并跳过bpf_perf_event_output
权限、命名空间与生产环境限制
即使程序逻辑正确，上线后也可能无声失效——这不是 bug，是内核机制。
- 需要
CAP_SYS_ADMIN或cap_sys_admin=ep，普通用户运行直接operation not permitted - 容器中默认禁用
unprivileged_bpf_disabled=1（尤其 Kubernetes），需在 pod securityContext 中显式开启：sysctls: [{name: kernel.unprivileged_bpf_disabled, value: "0"}] - 如果目标进程在 mount namespace 外（如宿主机路径），
openat(AT_FDCWD, "/etc/passwd")中的路径仍是相对宿主机的，但 Go 程序看到的是自己 namespace 下的挂载视图，容易误判路径归属 - 高频 open 场景（如日志轮转）会快速填满 perf buffer，建议设
ringSize := uint32(1024 * 1024)并实现lostHandler打印丢包数，而不是默认忽略
真正难的从来不是“怎么拿到 open 路径”，而是确保每条路径都来自你关心的进程、没被 namespace 隔离、没因 buffer 溢出丢失、且能在不同内核版本上持续工作。这些细节不写进日志，但一出问题就全暴露。
