Go context.WithValue Value 取不到时如何处理默认值

在请求链路里用 context.WithValue 传递租户、追踪标识或认证后的用户信息时，最容易踩的坑不是“值怎么写进去”，而是读取方默认认为它一定存在：userID := ctx.Value(userKey).(int64)。键不存在、键写错，或者中间层换了类型，这一行都会触发 panic。

更稳妥的做法是让访问器返回“值 + 是否存在”，在调用边界把缺失值转换为业务默认值。这样既不会掩盖类型错误，也能让下游函数拿到明确的输入。

先区分键不存在、显式 nil 和类型不匹配

Context.Value 找不到对应 key 时返回 nil。但“没有这个键”和“确实存了一个 nil”在业务上未必等价；另外，存入 int 却按 int64 读取，也会得到 ok == false。因此，默认值逻辑应建立在安全断言的结果上，而不是猜测 Value 的返回类型。

用私有 key 和类型安全访问器封装读取

把 key、写入和读取放在同一个小模块里，调用方只依赖 WithRequestID 与 RequestID。key 不使用字符串，避免不同包都写入 "request_id" 时互相覆盖。

package requestmeta

import "context"

// requestIDKey 使用私有类型，避免与其他包的上下文键冲突。
type requestIDKey struct{}

// WithRequestID 只把请求范围的追踪标识写入派生 Context。
func WithRequestID(ctx context.Context, id string) context.Context {
	return context.WithValue(ctx, requestIDKey{}, id)
}

// RequestID 用安全断言读取；缺失或类型不符时返回 false。
func RequestID(ctx context.Context) (string, bool) {
	id, ok := ctx.Value(requestIDKey{}).(string)
	return id, ok
}

这里的 requestIDKey{} 是零大小、可比较的自定义类型，同一个包内每次构造仍代表同一 key。若读取失败，访问器不 panic，而是把判断权交给调用方。

把默认值策略放在调用边界

如果业务允许没有请求 ID，可以在 handler 或服务适配层给出默认值；如果请求 ID 是审计必需字段，则应该返回错误。不要让底层仓储层悄悄把所有异常都变成 "unknown"，否则日志看似正常，问题却被隐藏。

package handler

import (
	"context"
	"errors"
)

var errMissingRequestID = errors.New("missing request id")

// requestIDOrDefault 只在业务允许匿名请求时使用默认值。
func requestIDOrDefault(ctx context.Context) string {
	if id, ok := requestmeta.RequestID(ctx); ok && id != "" {
		return id
	}
	// 这个默认值只表示“未提供”，不要冒充真实身份。
	return "anonymous"
}

// handleAudit 对审计入口拒绝缺失值，避免默认值掩盖责任主体。
func handleAudit(ctx context.Context) error {
	id, ok := requestmeta.RequestID(ctx)
	if !ok || id == "" {
		return errMissingRequestID
	}
	return saveAudit(ctx, id)
}

func saveAudit(ctx context.Context, id string) error {
	// 下游接收已完成校验的 id，不再重复猜测上下文内容。
	return nil
}

两个函数面对同一个读取失败可以有不同结果：展示型接口使用明确的匿名标识，审计接口返回错误。默认值不是 context 的特性，而是当前业务边界的选择。

检查 context.WithValue 的使用边界

官方文档建议 Context 作为函数的第一个参数传递，不要存进结构体；Value 只适合跨 API 边界传递的请求范围数据，不适合塞进分页大小、排序方式等普通可选参数。能直接写进函数签名的参数，就直接写进函数签名。

• key 必须可比较，并优先使用包内私有类型。
• 读取侧统一使用 value, ok := ctx.Value(key).(T)。
• 对“缺失”和“类型错误”需要不同处理时，让访问器返回错误或状态，而不是一律给默认值。
• Context 本身不要为 nil；暂时没有合适父上下文时使用 context.TODO()。

常见问题

ctx.Value(key) 返回 nil，直接断言为什么会 panic？

因为类型断言要求接口里存在目标动态类型；nil 接口没有可断言的动态类型。使用带 ok 的断言即可安全处理。

默认值能不能直接写在读取函数里？

可以，但只适合所有调用方都认可同一语义的基础元数据。若匿名、拒绝和重试等场景不同，应把策略留在调用边界。

用字符串 key 真的会出问题吗？

会。多个包可能使用同名字符串，导致值覆盖或读取到错误类型；自定义私有 key 能把碰撞范围限制在包内。

context.WithValue 能替代普通函数参数吗？

不建议。普通业务参数应显式传递，Value 只承载请求范围且需要沿调用链传播的元数据。

记住一个简单判断：先用安全访问器确认值是否存在，再由最接近业务决策的层选择默认值或错误。这样既能消除类型断言 panic，也不会把 Context 变成隐藏参数仓库。