Go context 里能放用户信息吗？请求作用域值和业务参数怎么分界

Go 的 context 可以放用户信息，但前提是它属于一次请求的横切元数据，例如认证后的 userID、traceID、租户 ID 或权限标记。它不适合放分页、筛选条件、订单状态、金额范围这类业务参数。简单判断就是：这个值是否随请求生命周期一起传递、是否被日志/鉴权/追踪等多层共享；如果只是某个函数完成业务逻辑需要的输入，就应该写进函数参数或请求结构体。

模式边界：context 只承载横切信息

context 最容易被误用，是因为它看起来像一条“万能暗线”：函数签名里只要有 ctx context.Context，就可以一路把值塞进去，再在任意下游取出来。短期看，参数少了；长期看，调用关系反而变得更难读。

更稳的边界是把 context 当作请求生命周期载体。取消、超时、追踪 ID、用户 ID、租户 ID 这类信息通常会穿过 Handler、Service、Repository、日志和监控。它们不属于某一个业务函数，而是和一次请求的处理过程绑定。

业务参数则不同。比如订单列表页的 page、status、sort，它们是“本次查询要怎么查”的显式输入。把它们放进结构体，调用者和被调用者都能看懂；把它们藏进 context，下游函数就需要猜测自己依赖了哪些隐形值。

适用压力：为什么用户信息会进入 context

在 Web 服务里，用户信息常常由鉴权中间件解析出来。中间件先检查 Cookie、Session、JWT 或内部网关头，再得到用户 ID、角色和租户信息。后面的 Handler、日志、审计和数据库访问都可能需要这些信息。

如果每一层函数都显式传 userID、traceID、tenantID，代码会变得很啰嗦；如果完全不传，下游又无法做权限、审计和日志关联。于是 context 就适合承担这类横切信息。

典型实现：中间件写入 userID 和 traceID

一个常见做法是为 key 定义私有类型，并提供小函数封装读写。这样可以避免不同包使用同一个字符串 key 时互相覆盖，也能把类型断言集中在一个地方。

package requestctx

import "context"

type userIDKey struct{}
type traceIDKey struct{}

func WithUserID(ctx context.Context, userID int64) context.Context {
    return context.WithValue(ctx, userIDKey{}, userID)
}

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

func WithTraceID(ctx context.Context, traceID string) context.Context {
    return context.WithValue(ctx, traceIDKey{}, traceID)
}

func TraceID(ctx context.Context) (string, bool) {
    traceID, ok := ctx.Value(traceIDKey{}).(string)
    return traceID, ok
}

在 HTTP 中间件里，鉴权通过后把用户 ID 放入请求上下文，再交给后续 Handler。Handler 不需要重新解析认证信息，只在需要时读取。

func AuthMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        userID, ok := verifySession(r)
        if !ok {
            http.Error(w, "unauthorized", http.StatusUnauthorized)
            return
        }

        ctx := requestctx.WithUserID(r.Context(), userID)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

这个模式的前提是：下游把 userID 当作请求身份，而不是把它当作“订单查询参数的一部分”。身份信息可以贯穿请求，具体业务输入仍然要显式传递。

反例：把分页和筛选条件藏进 context

下面这种写法看起来省参数，但会让 Service 和 Repository 对 context 产生隐式依赖。调用 ListOrders 的人只看到一个 ctx，却不知道它还必须带着分页和筛选条件。

type pageKey struct{}
type statusKey struct{}

func ListOrders(ctx context.Context) ([]Order, error) {
    page, _ := ctx.Value(pageKey{}).(int)
    status, _ := ctx.Value(statusKey{}).(string)

    return queryOrders(ctx, page, status)
}

这段代码的真正问题不是能不能运行，而是边界变暗了。单元测试要先构造一堆上下文值；新同事不知道缺哪个 key 会得到错误结果；重构时也很难搜索“订单列表依赖哪些参数”。

更清晰的写法是保留 ctx 传递取消和追踪，再用结构体表达业务输入：

type OrderQuery struct {
    Page   int
    Status string
    Sort   string
}

func (s *OrderService) ListOrders(ctx context.Context, q OrderQuery) ([]Order, error) {
    if q.Page 

这样函数签名会稍微长一点，但依赖是明的：ctx 负责请求生命周期，OrderQuery 负责业务查询条件。

后果：函数签名干净了，依赖却变隐蔽

误用 context.Value 的常见后果有四类：

• 测试变难：测试用例必须知道内部需要哪些 key，才能构造正确上下文。
• 重构变慢：参数依赖不在函数签名里，搜索调用点时容易漏掉上下文值。
• 错误变隐蔽：缺少某个值时，代码可能拿到零值而不是明确报错。
• 层次变混乱：Repository 可能偷偷读取页面筛选、用户角色、功能开关，边界越来越模糊。

所以判断 context 用得好不好，不是看函数参数少不少，而是看依赖是否仍然清楚。一个好的签名通常是：第一个参数是 ctx context.Context，后面跟清晰的业务参数或请求结构体。

判断清单：哪些值可以放进 context

写代码评审时，可以用下面这张清单快速判断。

如果仍然拿不准，可以反问一句：把这个值从 context 里删掉，函数签名是否会变得更真实？如果答案是肯定的，就应该把它从上下文里拿出来。

相关问题

context 里可以放完整 User 对象吗？

一般不建议。更稳的是放 userID 或少量身份字段，需要完整信息时由业务层按 ID 查询或使用明确的请求对象。完整对象太大、会变化，也容易把生命周期拉长。

为什么 key 不建议直接用字符串？

字符串 key 容易和其他包发生冲突。定义包内私有 key 类型，再提供读取函数，可以把冲突风险和类型断言集中管理。

所有函数都必须把 context 放第一个参数吗？

需要取消、超时、链路追踪或请求作用域值的函数，建议把 context.Context 放第一个参数。纯计算函数、简单值转换函数不一定需要接收 context。

没有 userID 时应该返回零值还是报错？

看调用场景。鉴权后的接口通常应该在入口就拦住无身份请求；业务层读取不到用户 ID 时，也应该返回明确错误，不要把 0 当成正常用户继续处理。

总结

context 可以放用户信息，但它适合放的是请求作用域元数据，不是所有业务输入。认证后的 userID、traceID、租户 ID 可以通过中间件写入上下文，方便日志、鉴权和追踪贯穿请求；分页、筛选、排序、表单字段则应该放在结构体或函数参数里。边界清楚后，代码会更容易读、容易测，也更不怕后续重构。