Go 中无 ThreadLocal，goroutine 本地存储靠显式传递 context.Context；推荐用私有类型作 key 的 context.WithValue，禁用字符串 key 和可变 value，不可依赖 goroutine ID。
Go 里没有 ThreadLocal，goroutine 本地存储靠什么？
Go 没有线程级的本地存储机制，goroutine 也不绑定 OS 线程，所以 ThreadLocal 这套根本不存在。实际开发中想存点“只属于当前协程”的数据（比如请求 ID、用户身份、trace 信息），唯一靠谱的方式是显式传递 context.Context，或用 sync.Map + 协程 ID 模拟——但后者极不推荐。
context.WithValue 是标准解法，但必须避开这几个坑
很多人以为 context.WithValue 就是 Go 的 ThreadLocal，其实它只是带键值对的只读上下文，不是存储容器。它的生命周期和 context 一致，且 key 类型必须可比较（不能用 string 当 key！容易冲突）。
- ✅ 正确做法：定义私有类型作 key，比如
type ctxKey string，再声明const userCtxKey ctxKey = "user" - ❌ 错误写法：
ctx = context.WithValue(ctx, "user_id", 123)—— 字符串 key 全局污染，不同包可能撞车 - ⚠️ 注意：value 不能是可变结构体或 map/slice，否则并发读写 panic；建议传指针或不可变值（如
int、string、struct{}）
为什么不用 goroutine ID 做本地存储？
有人试图用 runtime.Stack 解析 goroutine ID，再配 sync.Map 存数据。这方法在理论上可行，但实际完全不可靠：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- goroutine ID 不稳定：复用、调度、GC 都可能导致 ID 变化，尤其在 long-running 协程里
- 无法跨 goroutine 传递：HTTP handler 启的新 goroutine 拿不到父协程的“本地”数据
- 性能差：
runtime.Stack是昂贵的运行时调用，压测时会明显拖慢 QPS - Go 官方明确不保证 goroutine ID 的可用性，
runtime.GoroutineID()甚至不在标准库中
真实场景下怎么传透上下文？
典型 HTTP 请求链路里，从 http.HandlerFunc 到 service 层再到 DB 调用，每层都得把 ctx 当第一个参数传下去。这不是啰嗦，是 Go 的显式契约。
立即学习“go语言免费学习笔记（深入）”；
- 中间件注入：
ctx = context.WithValue(r.Context(), userCtxKey, userID) - 下游调用必须接收
ctx context.Context参数，比如db.QueryRowContext(ctx, ...) - 超时控制天然集成：
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)，cancel 后整个链路自动中断 - 别用全局变量“省事”存 ctx，一旦并发执行就错乱；也别在 struct 里缓存 ctx，容易泄露或过期
真正麻烦的不是写 ctx，而是漏传——只要一层忘了，后面全断。IDE 支持函数签名检查能帮上忙，但最终还得靠代码审查盯住 context.Context 的流向。
