go 官方不提供获取 goroutine id 的 api，因其非一等公民且不应被依赖；runtime.goroutineprofile 不适合取 id，因采样非实时、不唯一、暂停调度开销大；uuid 等方案与 goroutine 生命周期无关，易致逻辑错位；应使用 context.context 或 runtime.stack 哈希作轻量标识。
Go 语言官方不提供获取当前 goroutine ID 的公开 API，goroutine ID 不是 Go 的一等公民，也不该被依赖。
为什么 runtime.GoroutineProfile 不适合取 ID
有人试图用 runtime.GoroutineProfile 遍历所有 goroutine 并匹配栈帧来“猜”当前 ID，这既不可靠又开销大。
- 返回的 ID 是采样快照中的编号，非实时、不唯一（重启后重排）、不保证单调递增
- 调用本身会暂停所有 P，严重干扰调度，压测时可能直接拖垮性能
- 无法区分同名函数在不同 goroutine 中的调用栈，容易误判
go get -u github.com/gofrs/uuid 这类方案根本跑不通
第三方包如 github.com/gofrs/uuid 或 github.com/google/uuid 生成的是随机 UUID，和 goroutine 生命周期无关——它不能标识“这个 goroutine”，只能标识“这次调用生成的一个字符串”。
- goroutine 可能复用（比如从 pool 中取出），UUID 却每次新建，造成逻辑错位
- 若用于日志 trace，反而会让同一请求的多个阶段分散到不同 ID 下
- 真正需要关联上下文时，应该用
context.Context+context.WithValue或结构化字段，而不是伪造 ID
真要打日志或调试，用 runtime.Stack 提取轻量标识
如果你只是想在日志里区分 goroutine 行为（比如排查竞态或泄漏），可以用 runtime.Stack 抓一小段栈指针哈希，成本低、无副作用、够用。
func goroutineShortID() string {
buf := make([]byte, 32)
n := runtime.Stack(buf, false)
h := fnv.New32a()
h.Write(buf[:n])
return fmt.Sprintf("%x", h.Sum32())
}
- 返回值是 8 字符 hex 哈希，不是 ID，但足够在单次运行中做 goroutine 粗粒度分组
-
runtime.Stack(buf, false)不暂停调度，只抓当前 goroutine 的栈顶几帧 - 别存它、别传它、别做相等判断——它只适合打日志时加个前缀，例如
[g-8a3f1b2c] http handler start
真正难的不是“怎么拿到 ID”，而是意识到：你需要的往往不是 ID，而是可追踪的执行上下文。Go 的设计哲学在这里很坚决——别管它是第几个 goroutine，关心它“是谁启动的、属于哪个请求、带什么超时”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
