bpf_get_current_task()不能直接获取进程cpu时间，因其返回的task_struct指针无法安全访问utime/stime字段，因偏移不稳定且ebpf禁止任意内存读取；需改用sched_switch tracepoint+时间戳差值或perf_event_open实现。
为什么 bpf_get_current_task() 不能直接拿到进程CPU时间
因为 eBPF 程序运行在内核上下文，bpf_get_current_task() 返回的是 struct task_struct * 指针，但 eBPF 不允许任意内存读取（尤其是跨结构体字段偏移访问），而 task_struct 中的 utime/stime 字段位置不稳定、受内核版本和编译配置影响。硬编码偏移会立刻崩溃或返回垃圾值。
- 实际能安全访问的只有内核明确导出的辅助函数，比如
bpf_ktime_get_ns()或bpf_get_current_comm() - 统计 CPU 时间必须换思路：用时间戳差值 + 上下文切换事件，而非直接读进程计数器
- 主流可靠路径是挂钩
tracepoint:sched:sched_switch，记录每次切出时的rq_clock或用ktime_get_ns()做高精度打点
用 libbpf-go 挂载 sched_switch tracepoint 的关键步骤
Go 侧不能直接写 eBPF C 代码并加载，得靠 libbpf-go 加载预编译的 BPF 对象。核心不是“怎么写”，而是“怎么把时间戳塞进 map 并关联到 pid”。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在 eBPF C 部分定义一个
BPF_MAP_TYPE_HASH，key 为pid_t，value 为__u64 start_time（纳秒级） - 在
sched_switchtracepoint 的 eBPF 函数里：先查当前 pid 是否已在 map 中；若存在，用bpf_ktime_get_ns()减去存的start_time，累加到另一个 per-pid 的BPF_MAP_TYPE_ARRAY或BPF_MAP_TYPE_PERCPU_HASH中 - Go 侧用
obj.Maps.PidStartTimeMap.Lookup()和.Update()配合，但注意：map lookup/update 必须用unsafe.Pointer转换，且 key/value 大小必须严格匹配 C 定义 - 别忘了在 Go 中调用
link.AttachTracepoint()时指定event: "sched_switch"和group: "sched"，否则静默失败
perf_event_open() 方式比 tracepoint 更准，但 Go 里难落地
Linux perf_event 接口可直接读取 PERF_COUNT_SW_CPU_CLOCK 或 PERF_COUNT_HW_INSTRUCTIONS，精度更高且无调度延迟干扰。但问题在于：libbpf-go 当前不封装 perf_event_open() syscall，需自己用 golang.org/x/sys/unix 调用，还要处理 mmap ring buffer 解析。
- 必须手动设置
unix.PERF_FLAG_FD_CLOEXEC，否则子进程继承 fd 导致统计错乱 - ring buffer 解析要跳过 metadata header，按
struct perf_event_mmap_page规则读取数据块，Go 里没现成库，容易丢事件 - 每个 pid 开一个
perf_eventfd 开销大，实际建议只监控 top N 个 pid，用pidfd_open()（5.3+）绑定生命周期 - 如果只是看平均 CPU 使用率，tracepoint 已够用；真要微秒级指令周期分析，不如直接用
perf record -e cycles:u+go tool pprof
Go 读取结果时最容易踩的坑：map value 类型对齐和字节序
eBPF map 的 value 在 Go 里反序列化时，结构体字段顺序、padding、对齐必须和 C 端完全一致，否则读出来全是零或错位值。尤其当 value 是 struct（比如含 __u64 utime; __u64 stime;）时，unsafe.Sizeof() 必须等于 C 编译后的 sizeof()。
- 在 C 端用
_Static_assert(sizeof(struct cpu_time_val) == 16, "...");强制校验 - Go 侧定义对应 struct 时，字段名不必和 C 一样，但类型、顺序、数量必须一致；禁用
//go:pack，改用binary.Read()手动解析更稳妥 - 所有整数字段默认是小端，x86/ARM 都没问题，但别用
int——eBPF map 只认__u32/__u64，对应 Go 的uint32/uint64 - 别在 Go 循环里反复调用
Map.Lookup()查所有 pid；用Map.Iterate()流式读取，否则 map size > 1000 时性能断崖下跌
perf_event ring buffer 的指针是否越界。这些地方一错，数据就全空，还查不出错在哪。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
