Go 官方不提供稳定获取 goroutine ID 的 API，runtime.Stack() 解析的数字仅为调试用临时编号，会复用、无序、不唯一且格式易变；unsafe 读取 g.id 偏移不可靠，随版本和平台变化；应主动用 sync.Map 自管理 ID。
Go 语言官方不提供获取 goroutine ID 的 API，goroutine ID 不是 Go 运行时暴露的公开概念，任何声称“稳定获取”的方案都依赖未导出字段、汇编或调试接口，生产环境禁用。
为什么 runtime.Stack() 解析出来的数字不是可靠 goroutine ID
常见做法是调用 runtime.Stack() 获取堆栈字符串，再正则提取开头类似 goroutine 12345 [running]: 中的数字。但这只是运行时内部用于调试打印的临时编号，会复用、无序、不唯一（比如两个已退出的 goroutine 可能先后被分配到 ID 17），且在不同 Go 版本中格式可能变化（如 Go 1.22 起部分场景省略空格或调整冒号位置）。
- 它不反映调度状态，也不与
G结构体地址绑定 -
runtime.Gosched()或阻塞后再次解析，ID 很可能已变 - 在
go test -race模式下，输出格式可能额外包含检测标记，正则易失效
通过 unsafe 读取 g.id 的风险点
某些文章展示用 unsafe 偏移访问 g 结构体的 id 字段（如从 getg() 获取指针后 +0x168），但该偏移随 Go 版本、GOOS/GOARCH、是否启用 CGO_ENABLED=0 等剧烈变动。Go 1.21 在 src/runtime/runtime2.go 中已将 g.id 改为 uint64 类型，而之前是 int64；ARM64 下字段对齐也不同。
- Go 编译器不保证
g结构体布局稳定，甚至不保证g.id持续存在（未来可能彻底移除） - 使用
unsafe会导致二进制无法通过go vet安全检查，CI 流水线可能直接失败 - 交叉编译（如本地 linux/amd64 编译 darwin/arm64）时，偏移计算完全不可靠
真正可用的替代方案：用 map[*runtime.G]uint64 自管理 ID
如果确实需要区分 goroutine（例如日志追踪、资源绑定、调试统计），应主动在启动 goroutine 时分配唯一标识，并通过闭包或参数传递。推荐用 sync.Map 缓存 *runtime.G 指针到自增 ID 的映射：
立即学习“go语言免费学习笔记（深入）”；
var gIDMap sync.Map // map[*runtime.G]uint64
var nextID uint64 = 1
func getGoroutineID() uint64 {
g := getg()
if id, ok := gIDMap.Load(g); ok {
return id.(uint64)
}
id := atomic.AddUint64(&nextID, 1)
gIDMap.Store(g, id)
return id
}
// 使用示例：
go func() {
id := getGoroutineID()
log.Printf("goroutine %d started", id)
// ... work
}()
-
getg()是 runtime 内部函数，无需 import，返回当前*runtime.G指针 - 注意：goroutine 退出后，该映射不会自动清理，长期运行服务需按需回收（如配合
defer删除） - 若需跨 goroutine 传递 ID，避免依赖
getg()，改用显式传参或context.WithValue()
真正关键的不是“拿到 ID”，而是明确你到底想用它做什么——日志打标？性能采样？死锁检测？每种需求都有更安全、更符合 Go 设计哲学的解法，硬抠 g.id 只会让问题更难维护。
