Go context.WithValue 该不该存业务参数：键类型、请求链与可测试边界

接口里多塞一个 context.Context，很快就会遇到一个实际问题：用户身份、链路标识可以放进 context.WithValue，订单金额、分页大小和业务开关却不该跟着一起藏进去。边界划清，调用链会更容易读，测试也不会因为一份“神秘上下文”互相污染。

先把“请求信息”和“业务参数”分开

Go 官方对 context 的定位是传递截止时间、取消信号和请求范围内的值。它解决的是一条请求链上多个 API 需要共享少量元数据的问题，不是给函数增加一个无类型的参数抽屉。

例如 HTTP 中间件解析出 trace ID，日志组件、数据库调用和下游 RPC 都可能需要它。这类信息不会改变“计算订单折扣”的业务规则，放进上下文比较自然。反过来，discountRate、pageSize 和“是否跳过库存校验”会改变业务结果，就应该出现在函数签名或明确的配置对象里。

键类型决定了 WithValue 是否可靠

context.WithValue 要求 key 可比较。直接使用字符串虽然短，但不同包都写出 \"userID\" 时，值可能被意外覆盖或读错。更稳妥的做法是定义一个不导出的键类型：

package requestmeta

import "context"

type userIDKey struct{}

func WithUserID(ctx context.Context, id string) context.Context {
	return context.WithValue(ctx, userIDKey{}, id)
}

func UserID(ctx context.Context) (string, bool) {
	id, ok := ctx.Value(userIDKey{}).(string)
	return id, ok
}

这里的类型断言失败会返回 false，调用方可以决定是记录匿名请求、返回认证错误，还是继续使用默认行为。不要把断言写成无条件的 .(string)，否则一个缺失值就会变成 panic。

调用方需要什么，就在边界上说明什么

一个常见误区是让下层函数自己从 context 里拿所有输入：

func CalculatePrice(ctx context.Context) int {
	// 从 ctx 里取商品、数量、会员等级
	return 0
}

这种写法看似减少了参数，实际上隐藏了依赖。调用者必须先构造一串上下文，阅读函数签名也看不出缺哪些数据。更清楚的接口是：

type PriceInput struct {
	SKU      string
	Quantity int
}

func CalculatePrice(ctx context.Context, in PriceInput, memberLevel int) (int, error) {
	// ctx 只用于取消、截止时间和请求级元数据
	return in.Quantity * memberLevel, nil
}

ctx 仍然排在参数第一位，但业务输入被显式命名。这样既能响应取消，也能让单元测试直接构造 PriceInput，不用猜上下文里藏了什么。

用三组测试验收取值边界

围绕上下文值写测试时，重点不是证明 WithValue 能读回字符串，而是确认缺失、错误类型和父子覆盖都得到预期处理。

func TestUserID(t *testing.T) {
	ctx := context.Background()
	if _, ok := UserID(ctx); ok {
		t.Fatal("empty context must not contain user id")
	}

	ctx = WithUserID(ctx, "u-42")
	id, ok := UserID(ctx)
	if !ok || id != "u-42" {
		t.Fatalf("got %q, %v", id, ok)
	}
}

再补一组错误类型测试：用同名但不同类型的 key 写入，读取函数应保持缺失；用子 context 覆盖父值时，调用链应明确哪个层负责覆盖。测试里不要复用一个全局可变 context，避免用例顺序影响结果。

几个容易被误用的边界

不要把 context 存进长期对象

请求结束后，长期对象仍然持有 context，可能把请求级对象和取消关系延长到不该存在的生命周期。更常见的设计是每个方法接收当前请求的 context。

不要用 context 传可选参数

可选参数应该通过配置结构体、明确的 option 或函数参数表达。把它塞入 context 后，调用者无法从类型系统看到必需条件，也很难发现默认值在哪里产生。

缺失值要有稳定的回退策略

日志里的 trace ID 缺失可以落成空值或生成临时标识；认证主体缺失通常应该拒绝请求。把这两个场景都写成“没有就继续”，会把安全问题伪装成普通降级。

相关问题

context.WithValue 的 key 为什么不建议用 string？

因为不同包可能使用相同字符串，产生碰撞。自定义类型让键的类型身份也参与区分，包内封装读写函数会更稳妥。

context.Value 取不到值时应该返回什么？

优先使用带 ok 的类型断言，让调用方按场景处理缺失；不要为了省一行代码直接断言并承担 panic。

业务参数完全不能放进 context 吗？

如果它确实是贯穿请求边界的元数据，可以放；如果它改变业务计算、影响重试或授权决策，应改成显式参数或领域对象。

把规则落到接口评审上

评审一个带 context 的函数时，可以先问两句：这个值是否跨越多个 API 仍有意义？调用方是否需要从签名上看见它？前一个答案是否定时不必放入 context，后一个答案肯定时就应考虑显式参数。这样处理后，context 负责请求生命周期，业务接口负责业务事实，各自的测试边界也会清楚。