vscode 的 variables 或 watch 面板无法显示 runtime.g 字段，因 runtime.g 是未导出的内部类型，无反射支持且编译时默认裁剪调试符号；需用 dlv exec 模式配合 -gcflags="-n -l" 编译的二进制，并在 debug console 中执行 goroutines、regs、mem read 等底层命令间接访问。
VSCode 无法直接查看 runtime.g 结构体的底层字段（如 g.status、g.sched、g.m），因为 Delve 默认隐藏运行时内部结构，且 Go 编译器会对这些字段做符号裁剪和内联优化；只有在启用调试符号且使用特定 Delve 命令时，才能有限访问。
为什么在 VARIABLES 或 WATCH 面板里看不到 runtime.g
Delve 默认不暴露 runtime 包的未导出结构体字段，runtime.g 是纯内部类型，其内存布局随 Go 版本频繁变动，Go SDK 编译时还可能用 -gcflags="-l -N" 关闭调试信息以减小二进制体积——这会导致 Delve 根本读不到字段偏移量。
-
runtime.g不是 Go 语言层面的可导出类型，没有反射支持，fmt.Printf("%+v", g)会 panic 或打印空结构 - VSCode 的 VARIABLES 面板只显示当前栈帧中可解析的局部变量，
g是每个 goroutine 的隐式上下文，不在作用域内 - 即使你用
unsafe.Pointer强转当前 goroutine 指针，在 Delve 中也常因缺少类型定义而显示为void*，无法展开
用 goroutine <id> regs</id> 和 mem read 手动查 g.status
当程序在断点暂停后，可在 DEBUG CONSOLE 中结合 Delve 命令间接探测：先用 goroutines 获取目标 goroutine ID，再用底层命令读取其寄存器与内存。前提是 Delve 启动时已加载完整调试符号（即编译用了 -gcflags="-N -l"）。
-
goroutine 17 regs查看该 goroutine 的 CPU 寄存器，其中rax/rbx（amd64）或go寄存器（ARM64）常存有当前g地址 -
mem read -fmt uint32 -len 1 0x000000c000000180+0x14—— 假设g地址是0xc000000180，g.status在 offset0x14（Go 1.22 实测值，不同版本需查src/runtime/runtime2.go确认） - 更可靠方式：
goroutine 17 bt -a输出含runtime.gopark调用链，可反推其状态：若停在semacquire1，大概率g.status == _Gwaiting
用 dlv exec + -gcflags="-N -l" 编译才能稳定访问
普通 dlv debug main.go 使用的是临时构建，Go 默认开启优化，runtime.g 字段不可见；必须显式控制构建参数，让调试器拿到完整符号信息。
- 不要用
mode: "auto"或"debug"，改用"mode": "exec"，并确保program指向带调试信息的二进制 - 手动构建：运行
go build -gcflags="-N -l" -o ./debug-bin main.go，然后在launch.json中设"program": "${workspaceFolder}/debug-bin" - 验证是否生效：在 DEBUG CONSOLE 输入
types runtime.g，若输出字段列表（如stack、sched、status），说明成功；否则仍是incomplete type
真正实用的替代方案：用 runtime.ReadMemStats 和 debug.ReadGCStats 推断
硬啃 runtime.g 字段收益极低，且极易因 Go 版本升级失效；生产环境排查应转向可观测性接口——它们稳定、跨版本、无需调试器介入。
-
runtime.NumGoroutine()返回当前活跃 goroutine 总数，比数goroutines列表更轻量 - 在关键路径插入
debug.SetTraceback("all")，配合goroutine <id> bt -a</id>可看到完整栈，包括被内联掉的 runtime 函数 - 用
pprof.Lookup("goroutine").WriteTo(os.Stdout, 1)获取所有 goroutine 的文本快照，含状态（running/runnable/waiting）和阻塞点，比 Delve 更全
别花时间在 VSCode 里“展开” runtime.g —— 它不是设计来被 IDE 直接消费的。真正要盯的，是 goroutines 命令输出的 State 字段，以及 pprof 提供的 goroutine profile，这两者才反映真实调度行为。
