必须使用 tracepoint sched:sched_switch 而非 sys_enter_sched_yield，因其在每次实际上下文切换前触发并提供完整进程信息；需启用 BTF、自动生成 Go 结构体、正确解析 perf ring buffer 事件。
直接用 Go 调用 eBPF 监控上下文切换（context switch）不可行——Go 进程本身不参与调度事件的采集，必须依赖内核态 tracepoint 或 perf event，并通过 libbpf-go 安全读取；硬编码字段或用 cilium/ebpf 会导致参数为空、attach 失败或静默崩溃。
为什么 sys_enter_sched_yield 不是上下文切换的正确入口
很多人误以为 hook sched_yield 就能统计上下文切换，但 yield 只是主动让出 CPU，不等于实际发生了 switch。真正的上下文切换由内核调度器触发，对应 tracepoint 是 sched:sched_switch，它在每次实际切换前被调用，携带 prev_comm、next_comm、prev_pid、next_pid 等完整上下文信息。
-
sched:sched_switch是内核预埋的稳定 tracepoint，开销极低（纳秒级），且参数语义明确，是唯一推荐的起点 -
sys_enter_sched_yield或sys_enter_clone属于 syscall tracepoint，只能反映用户态意图，无法确认是否真发生切换 - 用 kprobe hook
__schedule或pick_next_task风险极高：函数签名随内核版本频繁变动，verifier 易拒绝，且可能因内联/优化导致 probe 插入点失效
libbpf-go 加载 sched_switch tracepoint 的最小可行配置
关键不在“怎么写 BPF C”，而在“如何让 Go 正确解析内核传来的结构体”。libbpf-go 依赖 BTF 自动推导字段偏移，否则 ctx->prev_pid 会读成垃圾值。
- 确保内核开启
CONFIG_DEBUG_INFO_BTF=y，并安装对应kernel-debuginfo包（如 RHEL/CentOS 用debuginfo-install kernel-core-$(uname -r)） - BPF C 中不要手动定义
struct sched_switch_ctx，直接用bpf_probe_read_kernel+ BTF 字段名访问：bpf_probe_read_kernel(&e->prev_pid, sizeof(e->prev_pid), &ctx->prev_pid) - Go 侧结构体必须用
btfgen自动生成，禁止手写；字段顺序、对齐、类型（如__u32对应uint32）必须严格一致 - 加载时指定
Tracepoint("sched", "sched_switch")，不是Kprobe("__schedule")
从 perf event map 读取数据时的并发与内存陷阱
perf event map 是上下文切换监控的数据通道，但直接循环 Map.Lookup 会卡死 goroutine，且并发读取易丢事件。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
PerfEventArray.Read()按 ring buffer 方式消费，每次读取返回原始字节流，需用预分配缓冲区解析（unsafe.Slice比binary.Read快 3–5 倍） - 每个事件结构体含 16 字节头部（
struct perf_event_header），必须跳过才能读到 payload；漏跳会导致后续所有字段错位 - 避免在 hot path 上做 JSON 序列化或深拷贝；高频场景下，把
prev_pid/next_pid提取为 uint32 后直接送入 metrics collector（如 prometheus.CounterVec） - 若需关联 Go goroutine，不能依赖
ctx->pid（这是内核线程 PID），而要结合/proc/[pid]/stack或 runtime/trace 的 goroutine ID 手动打标——二者无自动映射关系
真正难的不是加载 eBPF 程序，而是确保 BTF 可用、ring buffer 解析不越界、以及区分内核调度线程 PID 和用户进程 PID。这些细节一旦出错，看到的就全是 0 或随机数，而不是真实的切换行为。
