必须用uprobe而非kprobe，因runtime.casgstatus是用户态函数，kprobe无法挂钩；uprobe可无侵入捕获协程状态跃迁，且该函数在go 1.20+中稳定存在，参数明确指向*g地址与新状态值。
直接用 uprobe 挂到 Go 运行时函数上是最可行的路径，别试图从内核态读取 g 结构体——Go 的栈和内存布局在不同版本间不保证 ABI 稳定，bpf_probe_read_kernel 读 runtime.g 几乎必然失败。
为什么必须用 uprobe 而不是 kprobe
Go 协程状态变更（如 runtime.casgstatus）是用户态运行时函数，不在内核符号表里。kprobe 只能挂钩内核函数，对 libc 或 Go 二进制里的函数完全无效。uprobe 才是唯一能无侵入捕获协程状态跃迁的方式。
-
runtime.casgstatus是最稳定的 hook 点：它在每次协程状态变更（RUNNABLE → RUNNING、WAITING → RUNNABLE 等）时必被调用，且参数明确——ctx->ax是*g地址，ctx->cx是新状态值 - 不要选
runtime.newproc1：它只覆盖新建协程，漏掉调度唤醒、系统调用返回等关键路径 - Go 1.20+ 版本中
runtime.casgstatus仍存在且签名未变，但函数名可能被 LTO 优化为runtime·casgstatus，需用objdump -t ./binary | grep casgstatus确认真实符号
GOID_OFFSET 怎么确定才不崩
GOID_OFFSET 不是固定值，它取决于 Go 编译器生成的 g 结构体内存布局。硬编码 0x98 在 Go 1.19 上可能有效，但在 Go 1.21 的 CGO 开启/关闭、-gcflags="-l"（禁用内联）等条件下会偏移。必须动态解析。
- 用
go tool compile -S main.go查看汇编，找类似MOVQ (AX)(DX*1), CX中的偏移量，对应g.goid字段 - 更可靠的是用 BTF：如果目标二进制带 BTF（
go build -buildmode=exe -ldflags="-buildid="+strip --strip-debug前保留），eBPF 程序可通过bpf_core_read安全读取，无需硬编码偏移 - 若无 BTF，fallback 方案是用
bpf_probe_read_user分步读：先读g.sched.goid（该字段在多数版本中稳定位于+0x108左右），再验证是否为正整数，避免读到垃圾值
ringbuf 写入失败的常见原因
即使 bpf_ringbuf_reserve 返回非空指针，也不代表数据已成功提交——用户态消费端没及时 poll() 或 ringbuf 太小，会导致内核丢弃后续事件，且不报错。
- ringbuf 大小至少设为
256 * 1024（256KB）：单个goroutine_execute_data结构体约 64 字节，高并发下每秒数千事件，缓冲不足会静默丢数据 - 用户态必须调用
ringbuf.consume()（libbpf-go）或perf_buffer.poll()（bcc）持续消费，不能只启动一次就挂起 - 检查
/sys/kernel/debug/tracing/events/bpf/bpf_prog*/enabled是否为 1，防止 uprobe 被意外禁用 - 用
bpftool prog dump xlated name casgstatus确认指令中没有call bpf_probe_read_user失败跳转，否则整个 uprobe 会静默退出
真正难的不是挂上 uprobe，而是让 g.goid 和状态映射到可理解的业务上下文——比如把一个 goid=12345 关联到某次 HTTP 请求的 trace_id。这需要在用户态做跨数据源关联，而 eBPF 本身无法访问 Go 的 context.Context 或 HTTP header，必须靠额外 uprobe（如 net/http.(*ServeMux).ServeHTTP）打点并共享 key，这点极易被忽略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
