runtime.Stack 是目前唯一合法获取 goroutine ID 的方式，通过解析 panic 日志首行 "goroutine N [state]:" 提取数字，需注意缓冲区大小、正则匹配、禁用 all=true 等细节。
runtime.Stack 解析 goroutine ID 是唯一“合法”的方式
Go 官方不提供 runtime.GoroutineID() 或类似导出函数，runtime.Stack 是目前唯一无需修改运行时、不依赖汇编、兼容所有 Go 版本（1.4–1.22+）的可行路径。它利用 panic 日志中固有的格式特征——第一行必为 "goroutine N [state]:" ——反向提取数字。
常见错误现象：缓冲区太小导致截断（如只用 [64]byte 在深度调用栈下漏掉 ID）、未处理空格或换行导致 strings.Fields 取错字段、panic 后 recover 逻辑干扰解析。
- 缓冲区建议至少
256字节，避免栈信息被截断 - 不要依赖
strings.TrimPrefix+strings.Fields的组合，用正则^goroutine (\d+)更鲁棒 - 务必设
all = false，否则会触发全局 stop-the-world，线上绝对禁用 - 该操作是同步阻塞的，单次调用耗时约 0.1–0.5ms，高频日志场景会明显拖慢吞吐
为什么 getg() 汇编方案已被淘汰且危险
早期有人通过内联汇编调用未导出的 runtime.getg，再读取其返回结构体的 goid 字段。这在 Go 1.3–1.9 时代曾有第三方库（如 petermattis/goid）支持，但自 Go 1.10 起，g 结构体布局频繁变更，字段偏移失效、字段重命名、甚至字段删除都发生过。现在硬编码地址等于给程序埋雷。
使用场景仅剩极少数离线调试工具链，且必须绑定特定 Go 版本二进制。线上服务、CI 构建、跨版本容器镜像全部不可用。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Go 1.17+ 彻底移除了部分 g 结构字段注释，汇编代码失去可读性和可维护性
- go tool compile 对内联汇编检查更严，某些版本直接报错
unsupported instruction - 静态链接时若混用不同 Go 版本的 libgo.a，
getg返回值可能指向非法内存
替代思路：用 trace ID 或 context.Value 代替 GID
真正需要区分 Goroutine 的场景，90% 不是“我要知道它是第几个”，而是“我要让这条日志/请求/错误能串起来”。这时硬塞一个递增数字毫无意义，反而掩盖了因果关系。
推荐做法是用 context.WithValue 注入短生命周期 trace ID，或用 log/slog 的 With 方法挂载键值对。它们天然支持传播、过滤、采样，且无性能陷阱。
- 避免用 Goroutine ID 做 map key 或做 local storage —— Go 运行时明确反对，GC 无法追踪这类引用
- 日志中写
"trace_id=abc123, goroutine=18"看似全面，实则 trace_id 已足够定位，GID 只是冗余噪声 - 若真需轻量级标识，启动 Goroutine 时生成随机 6 字符 ID（
rand.Intn(62)映射 a-z/A-Z/0-9），可控、无冲突、零开销
官方态度不是“技术做不到”，而是“你不该依赖它”
Go 团队在 FAQ 和多次 proposal 讨论中反复强调：goroutine 是调度单元，不是身份凭证。它的生命周期短、数量大、复用频繁，ID 数字本身无业务语义。强行捕获并暴露它，会诱使开发者写出耦合调度细节的代码，比如基于 GID 分片缓存、GID 绑定 TLS、GID 控制并发数等——这些模式在 Go 的 M:N 调度器演进中极易崩坏。
最常被忽略的一点：即使你今天用 runtime.Stack 安全拿到了 ID，Go 运行时文档也白纸黑字写着：“stack trace format is not part of the API；it may change without notice”。这意味着下个 patch 版本（比如 1.22.1）就可能把 "goroutine 42 [running]:" 改成 "[G42 running]:"，你的解析逻辑当场失效。
