eBPF程序运行在内核态，无法调用用户态Go运行时函数，time.Now()会因违反eBPF验证器规则而编译失败或被拒绝；必须使用内核提供的bpf_ktime_get_ns()等辅助函数获取时间戳。
为什么不能直接用 Go 的 time.Now() 在 eBPF 中测函数耗时
eBPF 程序运行在内核态，无法调用用户态的 Go 运行时函数，time.Now() 会编译失败或触发 verifier 拒绝。eBPF 只能使用内核提供的辅助函数，比如 bpf_ktime_get_ns()——它返回的是单调递增的纳秒级时间戳，且被 verifier 明确认可。
常见错误现象是：在 eBPF C 代码里写 clock_gettime() 或 gettimeofday()，结果 libbpf 加载时报 invalid bpf_context access 或 unknown helper function。
- 必须用
bpf_ktime_get_ns()（不是bpf_ktime_get_boot_ns()，后者含休眠时间，不适合执行耗时统计） - 两次调用之间不能跨 CPU，否则时间戳不可比（但同一 tracepoint/kprobe 的 entry/exit 天然在同一 CPU 上）
- 不要在 eBPF 中做减法后立刻除以 1e6 转毫秒——整数除法精度丢失严重，建议用户态后处理
如何用 kprobe + map 关联函数 entry/exit 时间戳
核心思路是：在函数入口（do_sys_open 等）打 kprobe，记录 pid+tgid+cpu 为 key、进入时间戳为 value；在出口（do_sys_open+0xXX 或 retprobe）再查这个 key，算差值并存入另一个 map（如 histogram）。
关键点在于避免 key 冲突：同一进程可能重入同个函数（比如递归或信号中断），所以仅用 pid 不够，得加 cpu 或栈指针低位（但栈指针不稳定），最稳妥是用 __builtin_preserve_access_index(&ctx->regs) 配合 PT_REGS_RC(ctx) 做 exit 匹配，不过简单场景用 pid+tgid+cpu 已足够。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- entry map 类型推荐
BPF_MAP_TYPE_HASH，key 为struct { u32 pid; u32 cpu; }，value 为u64（时间戳） - exit 时先
bpf_map_lookup_elem()，查不到就丢弃（说明 entry 事件丢了，或 map size 不够） - 别忘了在 exit 分支里
bpf_map_delete_elem()对应 key，防止 map 填满
Go 用户态如何安全读取和聚合 eBPF 时间数据
Go 程序通过 github.com/cilium/ebpf 库加载程序、读 map。难点不在读，而在“怎么读不丢数据”和“怎么聚合有意义”。比如每秒读一次 histogram map，但 eBPF 端是原子更新，用户态读时可能正被内核修改。
典型误操作：用 Map.Lookup() 循环遍历所有桶，但没考虑 map resize 或并发更新导致的迭代器失效——表现为 no such file or directory 错误或 panic。
- 对计数类 map（如直方图），优先用
Map.GetNextKey()+for循环，而非Map.Lookup()直接取全部 - 读完立即
Map.Delete()清空（如果设计为“读即清空”模式），避免重复统计 - 聚合建议在 Go 侧做：比如把纳秒转为微秒后
bucket := int(math.Log2(float64(us)))做对数直方图，别在 eBPF 里算 log（没有浮点指令）
实际部署时最常被忽略的权限与符号问题
即使代码全对，permission denied 或 failed to find symbol 'do_sys_open' 依然高频出现。这不是 Go 或 eBPF 的 bug，而是运行环境没对齐。
比如 Ubuntu 22.04 默认用 kernelstub 启动，/proc/kallsyms 对非 root 不可见；又或者内核编译时关了 CONFIG_KPROBE_EVENTS，导致 kprobe 加载失败。
- 必须用
sudo运行 Go 程序（或配置cap_sys_admin） - 检查
cat /proc/sys/kernel/kptr_restrict是否为0（否则kallsyms地址全为 0） - 用
bpftool feature probe确认当前内核支持kprobe_multi或trampoline（新版本推荐后者） - 函数名要和
/proc/kallsyms严格一致：比如sys_openat和__x64_sys_openat是不同符号，后者才是 v5.10+ 的真实入口
真正麻烦的从来不是怎么写那几行 eBPF 代码，而是确认目标函数是否真的被内核导出、kprobe 是否能稳定 attach、以及用户态读 map 时有没有被其他进程干扰。这些细节不验证，跑起来就是“看起来有数据，但全是零或跳变”。
