Go标准库不提供获取当前goroutine唯一ID的API，runtime.GoID()实际并不存在；官方明确拒绝添加该功能，因其违背goroutine作为调度单元而非身份实体的设计哲学，所有试图通过反射、汇编或解析runtime.Stack获取ID的方法在Go 1.20+均已失效或不可靠。
Go里根本没有协程ID，runtime.GoID() 不存在
直接说结论：Go标准库不提供获取当前goroutine唯一ID的API，runtime.GoID() 是民间流传的“黑科技”名称，实际并不存在。官方明确拒绝添加该功能，理由是goroutine设计上就不该被标识或跟踪——它只是调度单元，不是身份实体。
常见错误现象是有人在GitHub或博客里搜到伪造的runtime.GoID实现，试图用反射或汇编硬抠g结构体里的字段（比如g.id），但这些方法在Go 1.14+几乎全部失效：g结构体已移入runtime内部包、字段重命名、内存布局随机化，且不同版本ABI不兼容。
- Go 1.17起，
g结构体彻底从runtime2.go中移除公开定义，连unsafe定位都不可靠 - 哪怕临时hack成功，一旦升级Go版本，程序大概率panic或静默错乱
- 所有基于
g.stackguard0、g.goid等字段的“取ID”代码，在Go 1.20+编译不过
真正可用的替代方案：用context.Context携带逻辑ID
如果你需要区分不同goroutine的执行上下文（比如日志追踪、超时控制、链路标记），正确做法是显式传递标识，而不是反向扒ID。最稳妥的是用context.WithValue注入一个int64或string类型的逻辑ID：
ctx := context.WithValue(context.Background(), key, atomic.AddInt64(&counter, 1))
go func() {
id := ctx.Value(key).(int64)
log.Printf("goroutine %d started", id)
}()
注意：key必须是自定义类型（避免与其他库冲突），不能用string或int直接当key；atomic.AddInt64比rand.Int63()更可控，避免重复或碰撞。
立即学习“go语言免费学习笔记（深入）”；
- 不要用
goroutine ID做权限校验或状态绑定——goroutine可被调度器复用，ID无语义 - 若需跨goroutine传递状态，优先用
context而非全局map+goroutine ID查表 - 性能影响极小：一次
WithValue是O(1)指针赋值，比任何反射或汇编hack快两个数量级
为什么非要ID？先确认你是不是真需要它
很多场景其实误把“调试需求”当成“运行时需求”。比如想在pprof或trace中区分goroutine，Go原生支持：runtime.SetBlockProfileRate()、runtime/pprof.Lookup("goroutine").WriteTo()输出的堆栈本身就含goroutine创建位置，无需ID；又比如日志打点，用log.WithContext(ctx)比硬塞ID更符合Go惯用法。
- 排查死锁？用
go tool trace看goroutine状态图，ID反而干扰判断 - 做并发限流？按业务维度（用户ID、请求路径）限，不是按goroutine数限
- 实现Worker Pool？worker本身是对象实例，ID应由池管理器分配，与底层goroutine解耦
性能评估结果：别测了，没意义
所有号称“微秒级获取goroutine ID”的bench测试，前提都是基于已失效的旧版runtime结构体。在Go 1.22下实测：任何尝试读取g私有字段的代码，要么编译失败，要么触发invalid memory address panic。所谓“性能对比”，实际测的是崩溃速度。
真正有意义的性能数据是：context.WithValue开销约3ns，runtime.GoroutineProfile全量采集约20μs（且会暂停调度器），而任何unsafe操作在新版Go里已失去可复现性——它不是慢，而是不可用。
复杂点在于：人容易把“我能拿到地址”当成“我能安全解读”，但Go runtime的g结构体不是C struct，它是带GC元信息、栈寄存器映射、抢占信号位的动态块，字段偏移随时变。这个事实比任何性能数字都重要。
