go语言无协程本地存储，唯一可靠方式是显式传递context.context；runtime.goroutineid()不可用，因非标准库、id复用、断链且go vet警告；context.withvalue的key须为私有类型，取值需类型断言+ok判断，goroutine启动必须手动传入子ctx。
Go 语言没有协程本地存储（GLS），任何试图模拟的方案都不可靠，也不被官方支持。唯一安全、可长期依赖的方式是显式传递 context.Context。
为什么不能用 runtime.GoroutineID() 做本地存储
这不是“不推荐”，而是根本不可用：
-
runtime.GoroutineID()不在标准库中，所有实现都依赖未承诺的运行时内部结构（比如g.goid），go vet在 Go 1.21+ 已报警告，1.23+ 构建环境可能直接拒绝编译 - goroutine ID 会被复用：net/http 的 handler 协程池、长时间运行的 goroutine 都会导致 ID 重复，映射数据错乱
- 新启动的 goroutine（如
go db.QueryRowContext()）拿不到父协程的 ID，天然断链 -
runtime.Stack()是同步阻塞调用，单次耗时微秒级，QPS 高时直接拖垮吞吐
context.WithValue 的 key 必须是私有类型
用字符串当 key 是线上事故高发区，不同包定义同名字符串 key 会互相覆盖：
- ✅ 正确写法：
type userKey struct{}，然后ctx = context.WithValue(ctx, userKey{}, userID) - ✅ 空 struct
struct{}或未导出 struct（如userKey）零内存开销、可比较、跨包隔离 - ❌ 错误写法：
context.WithValue(ctx, "user_id", 123)—— 全局 key 空间无隔离 - ❌ 导出类型（如
public.Key）或int作 key：易冲突，且无法跨包控制唯一性
取值必须做类型断言 + ok 判断
ctx.Value() 返回 interface{}，裸断言会 panic：
- ❌ 危险：
id := ctx.Value(userKey{}).(string)—— key 不存在或类型不匹配时直接崩溃 - ✅ 正确：
if v, ok := ctx.Value(userKey{}).(string); ok { /* 使用 v */ } else { /* fallback 或 error */ } - 建议封装提取函数，如
func UserIDFromCtx(ctx context.Context) (string, bool)，统一处理缺失逻辑 - HTTP middleware 注入的值，下游 handler 必须通过该函数取，禁止裸调
ctx.Value
goroutine 启动时必须手动传入子 ctx
Go 关键字不会自动传播 context，这是防止 goroutine 泄漏的关键控制点：
- 必须显式衍生子 ctx：
ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second) - 子 goroutine 函数签名必须接收
ctx，并在内部defer cancel()（若用WithCancel） - 禁止在 struct 字段里缓存
context.Context：它不是状态容器，是控制流信号载体，缓存会导致过期或泄漏 - 中间件注入后，下游所有函数（包括
DB.QueryRowContext、http.Client.Do）都需接收并使用该ctx
真正容易漏掉的，是那些看似“无关紧要”的 goroutine 启动点——比如日志异步刷盘、指标上报、清理任务。它们一旦没接 ctx，就既无法超时退出，也无法响应取消信号，变成隐形泄漏源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
