go官方不提供且有意不实现getgoroutineid()，因其id非稳定标识，暴露会鼓励错误并发模型；应使用context.context传递请求上下文，而非依赖goroutine id。
Go 语言官方不提供获取 goroutine ID 的接口，goroutine 本身没有稳定、可导出、可用于逻辑判断的 ID。 试图获取或依赖它，大概率是设计出了偏差，或者想用它做本不该做的事（比如日志追踪、上下文绑定、资源隔离等）。
为什么 GetGoroutineID() 不存在且不该被实现
Go 运行时明确隐藏了 goroutine 的内部标识：它的调度单位是 m（OS 线程）、g（goroutine）、p（处理器），但 g.id 是运行时内部编号，不保证唯一跨重启、不保证递增、不保证生命周期内不变，更不会暴露给用户代码。强行通过 runtime.Stack() 解析堆栈、或用 unsafe 读取 g 结构体字段，属于未定义行为——Go 1.21+ 已让这类操作更难奏效，且每次版本升级都可能崩。
常见错误现象：panic: unsafe pointer conversion、解析出的数字重复/跳变/为 0、在 CGO 或 panic 恢复路径中失效。
- 不是“还没加”，而是“有意不加”——Go 团队认为暴露它会鼓励错误的并发模型
- 所有声称“稳定获取 goroutine ID”的第三方包，底层要么解析堆栈（慢、不可靠），要么用
unsafe（脆弱、禁用在生产环境） - 如果你在写中间件或日志库，指望靠 goroutine ID 做 trace，那真正该用的是
context.Context+trace.Span
替代方案：用 context.Context 代替 goroutine ID
绝大多数你想要 goroutine ID 的场景，其实是要区分“这次请求”或“这个任务”的执行上下文。这时 context.WithValue() 或自定义 context.Context 实现才是正解。
例如日志打标：
ctx := context.WithValue(context.Background(), logKey{}, "req-7f3a")
go func(ctx context.Context) {
log.Printf("handling %v", ctx.Value(logKey{})) // 输出 req-7f3a
}(ctx)
要点：
- 不要用
int或string当 key，定义私有类型避免冲突：type logKey struct{} - 如果需要唯一标识，用
uuid.NewString()或atomic.AddUint64(&counter, 1)生成 request ID，传入 context - goroutine 起始处就注入 context，别等中间某层再“查 ID”——这违背 Go 的显式传递哲学
调试时临时看 goroutine 编号：用 runtime.GoroutineProfile() 或 debug.ReadGCStats()
仅限诊断，不能用于业务逻辑。比如你想确认是否 goroutine 泄漏：
var buf [1 <p>输出里每段开头类似 <code>goroutine 19 [running]:</code> 的 <code>19</code> 就是当前运行时分配的内部编号。但它：</p>
- 只在调用瞬间有效，下一纳秒可能已被复用
- 不同进程、不同 GC 周期，相同数字不代表同一个 goroutine
- 无法从外部 goroutine 获取另一个 goroutine 的这个编号
真正要区分并发执行流，靠的是你主动构造的标识（request ID、task ID、trace ID），不是运行时偷偷给的编号。越早放弃找 goroutine ID，越早写出可测、可维护、不被 Go 版本卡脖子的代码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
