Go 没有原生协程本地存储（GLS），运行时不暴露协程ID或本地存储接口；官方推荐用 context.Context 传递请求级数据，第三方GLS库依赖未承诺实现且存在兼容性与泄漏风险。
Go 没有原生 GLS，go 运行时也不暴露协程 ID 或本地存储接口
Go 语言标准库中不存在类似 Java ThreadLocal 或 libgo 的 CLS 那样的协程本地存储（GLS）机制。运行时内部虽用 TLS（通过 getg() 获取当前 g 结构体）管理协程上下文，但该能力不对外暴露，任何试图从 runtime 包提取 goid 并用于映射数据的做法都属非稳定行为——Go 1.22+ 已明确警告 goid 可能重复、不可靠，且未来版本可能移除。
这意味着：你不能安全地基于 goid 构建长期可用的 GLS。所有第三方库的“协程本地”效果，本质是模拟，不是语言级保障。
context.Context 是 Go 官方推荐的、最轻量且可组合的替代方案
当你要传递请求生命周期内的数据（如 traceID、用户身份、超时控制），context.Context 是唯一被 Go 团队设计并维护的机制。它天然支持协程传播、取消和截止时间，且无额外依赖或运行时风险。
- 必须显式传递：每次调用子函数或启动新协程时，把
ctx作为第一个参数传入 - 避免在结构体字段里存
context.Context：它不是状态容器，而是控制流信号载体 - 不要用
context.WithValue存业务实体（如*User）：应只存元数据；业务对象建议封装进自定义 struct 并随 ctx 一并传参 - 启动协程时用
context.WithCancel或context.WithTimeout衍生子 ctx，防止 goroutine 泄漏
第三方库如 go-eden/routine 和 timandy/routine 能工作，但有硬伤
这类库确实提供了 LocalStorage.Set() / Get() 接口，看起来像 GLS。但它们依赖的是运行时未承诺的实现细节：
-
go-eden/routine用unsafe读取g.goid，在 Go 1.21+ 上已触发 vet 报警；1.23 后部分构建环境直接拒绝编译 -
timandy/routine改用协程启动时注入 ID，绕开了 goid，但要求你必须用它的Go()替代原生go关键字，破坏代码一致性 - 两者都不兼容
runtime/trace或pprof的协程标签功能，调试时看不到真实归属 - 无法跨 CGO 边界或 syscall 阻塞点保持值——协程挂起再恢复后，本地值可能丢失
自己用 sync.Map + 协程 ID 模拟？别这么做
有人尝试用 sync.Map 存 goid → value 映射，看似简单。但问题比想象中严重：
-
goid不唯一：复用的 goroutine（比如net/httpserver 复用的 handler 协程）会拿到相同 goid，导致数据污染 -
sync.Map本身不适合高频写：每个协程首次 Set 就是一次写操作，而sync.Map的写性能远低于带sync.RWMutex的普通 map - 没清理逻辑：goroutine 退出后，map 中的条目永远残留，内存泄漏不可避免
- 没有继承语义：父协程设的值，子协程拿不到，除非你手动 copy —— 那还不如用
context
真正需要“协程局部状态”的场景极少，多数时候是误把控制流需求当成存储需求。优先检查是否能用 context 重构，而不是造一个脆弱的 GLS 替代品。
