context.withvalue仅适用于传递只读、不可变的请求元数据（如traceid、userid），因其不提供同步机制，无法支持业务状态（如订单阶段、重试次数）的并发读写与通知等待，应改用sync.map/channel/sync.cond等原语管理可变状态。
不能用 context.WithValue 传业务状态，只能传请求元数据（如 traceID、userID），且必须是只读、不可变、生命周期与请求一致的值。
为什么 context.WithValue 不适合传业务状态
业务状态（比如订单当前阶段、缓存是否命中、重试次数）天然具有可变性，而 context.Value 返回的是只读副本；一旦协程间需要修改、通知、等待某个状态变化，context 就完全无能为力。强行塞进去会导致：
- 多个 goroutine 并发读写同一 key，但 context 不提供同步机制，极易出现竞态
- 调用
ctx.Value(key)拿到的永远是创建时的快照，后续修改对其他 goroutine 不可见 - 误以为“传进去了就能共享”，结果调试时发现各处读到的值不一致，排查成本极高
真正该用什么同步业务状态
业务状态变更需满足「通知 + 等待 + 可变」三要素，context 只负责前两者中的“通知”（通过 Done()），状态本身必须交由其他并发原语承载：
- 状态本身用
sync.Map或带互斥锁的 struct 管理（注意：不是放 context 里，而是独立存在，多个 goroutine 共同访问） - 状态变更时，用
channel或sync.Cond通知关心者（例如：订单从 “processing” → “success”，通知下游日志协程 flush） - 若需等待某个状态达成（如“等缓存写入完成”），不要轮询
ctx.Value，改用select等待对应 channel 关闭或接收信号
示例场景：一个请求启动了 DB 查询和缓存预热两个 goroutine，需等缓存写完再返回响应：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
cacheDone := make(chan struct{})
go func() {
// ... 写缓存逻辑
close(cacheDone)
}()
select {
case
<h3>
<code>context.WithValue</code> 的唯一合规用法</h3>
<p>仅限传递**请求作用域内不可变的元数据**，且 key 类型必须是自定义未导出类型，避免冲突：</p>
- 必须用私有类型做 key：
type ctxKeyUserID struct{}，而非string或int - 值必须是只读结构体、字符串、数字等不可变类型（禁止传指针、map、slice）
- 典型用途：HTTP 中间件注入
userID、traceID、tenantID，供日志、监控、鉴权层读取 - 绝不用于传递“当前步骤编号”“重试计数器”“临时计算结果”这类会随执行推进而变化的数据
容易被忽略的坑：value 传递链断裂
context.WithValue 创建的新 context 只对其直系子 goroutine 有效；如果中间某层 goroutine 忘记把 context 作为参数传下去（比如漏写了 ctx 参数，或错误地用了 context.Background()），下游就再也拿不到该 value。常见于：
- 调用第三方库函数时，没确认它是否接受并透传 context（如某些老版本
database/sql驱动） - 在
http.HandlerFunc中启动 goroutine，却直接用req.Context()而非显式传参，导致子 goroutine 无法继承 value - 使用
goroutine pool或异步任务队列时，context 未被正确绑定和传递
真要跨多层传递可变状态，别绕弯子——用显式参数 + 同步原语，比硬套 context 更直白、更可控、更容易测试。
