Go 上下文Background 值传递导致请求数据泄漏怎么办

Background 本身没有请求值，也不会自动记住上一个用户。看到请求数据串用时，我会先查带值的派生上下文是否被保存到全局变量或共享服务字段，再查 Value 中是否放了跨请求共用的 map、切片或指针。修复方向是每次请求单独派生、沿调用参数传递，并限制值的共享范围，而不是把 Background 换一个名字。

下面用一个假设场景说明：两个浏览器请求在服务端日志里显示了不该相同的请求数据。本文不声称发生过真实泄漏，也没有执行示例测试。有关上下文行为的说明来自 Go 官方文档；示例只演示请求关联号，不实现身份认证。

官方地址：https://pkg.go.dev/context

Background 不是保存请求值的全局字典

调用 WithValue 会返回一个关联父上下文的新上下文，不会往父级写入一条全局记录。两个从空根分别派生的请求，可以使用同一个私有键，却各自保存不同值；读取某个子上下文，也不会自动查到它的兄弟上下文。

我认为最值得警惕的是“方便复用”的那层代码：把上一次派生结果回写到共享变量，再拿它当下一次请求的父级。如果第二次没有覆盖某个键，它可能沿父链读到以前的值。即使加锁消除了并发读写竞争，这条错误的继承链仍然存在；线程安全不等于请求隔离。

另一类问题不在上下文链本身：两个请求存入的是同一个可变对象。WithValue 不是深拷贝工具，封装指针不会复制其指向的数据。上下文接口允许并发使用，不等于其中任意业务对象都自动获得并发保护。

先确认请求隔离和取消的适用范围

浏览器发来的 HTTP 请求不直接携带一个 Go Context 对象；服务端框架为处理过程提供上下文。对 net/http 服务，我会从当前 r.Context 开始派生，而不是在中间层重新创建 Background，把原来的取消关系丢掉。

标准 HTTP 服务端会在客户端连接关闭、HTTP/2 请求取消或 ServeHTTP 返回时取消相应请求上下文。下游仍需要把 ctx 传给支持上下文的操作，取消不会神奇地停止完全忽略它的代码。

进程初始化、独立后台任务可以有自己的根上下文，但这不是延长所有请求数据寿命的理由。先判断任务究竟归请求所有，还是由独立任务系统接管，再选择父级和数据契约。不要用“不超时了”来判断串值问题已经解决。

我会在每次请求内创建自己的派生值

下面是可集成到现有服务的中间件包，不包含服务器启动代码。它在每次调用中生成关联号，使用包内私有键保存一个字符串，再把派生请求交给下游。没有全局请求上下文，也没有共享可变请求资料。

package requestscope

import (
    "context"
    "crypto/rand"
    "encoding/hex"
    "net/http"
)

// 私有可比较键只由本包的访问函数使用，避免跨包键名碰撞。
type requestIDKey struct{}

// RequestID 返回请求关联号；关联号不是登录凭据或授权结论。
func RequestID(ctx context.Context) (string, bool) {
    id, ok := ctx.Value(requestIDKey{}).(string)
    return id, ok && id != ""
}

// WithRequestID 在每次调用内建立新值，不改写共享上下文变量。
func WithRequestID(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        var token [16]byte
        if _, err := rand.Read(token[:]); err != nil {
            // 不回显随机源错误细节，失败时不进入下游。
            http.Error(w, "请求初始化失败", http.StatusInternalServerError)
            return
        }
        id := hex.EncodeToString(token[:])
        // 继承本次请求的取消与超时，只附加一个小型标量值。
        ctx := context.WithValue(r.Context(), requestIDKey{}, id)
        w.Header().Set("X-Request-ID", id)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

下游通过 RequestID 访问函数读取，不需要知道键类型。返回的 bool 用来表达值缺失，不能悄悄退回某个全局“最近用户”。关联号由服务端生成，但它依然不是认证凭证，也不是租户权限证明；本例没有读取客户端提交的用户号或租户号。

示例只有一段小型标量信息。业务服务若需要 ctx，就把它作为显式参数传下去；若需要订单号、过滤条件或其他普通业务参数，就继续使用函数参数或专门结构，不必把整个业务接口藏进 Value。

旧代码迁移时别把断开取消当作脱敏

迁移时我会先找长寿命对象中的请求 ctx 字段和闭包捕获，再把它们改为每次调用传参。共享服务仍可以保存连接池、配置等进程资源，但不应把某一请求的派生上下文作为以后请求的隐式默认值。将字段名改成 baseCtx，并不能改变它仍然带有旧请求值的事实。

如果键由多个包共同使用，应由一个包定义键和访问函数；不要让每个包都使用相同字符串猜测数据。私有键解决的是碰撞风险，不验证数据可信度，也不代替访问控制。

Go 1.21 起提供 WithoutCancel。它用于派生一个不随父级取消的上下文，不是“清空请求资料”的接口；其 Value 仍沿父级查找，且没有原来的截止时间。不能拿它当作脱敏或请求隔离方案。需要让独立任务只保留少量数据时，应设计明确字段的任务载荷，把允许保留的信息逐项取出，并设置独立期限；其中的身份信息仍需按业务要求校验和授权。

让值的体积和使用范围保持可控

对我来说，小而明确的请求值比“放进去以后随处能取”更好维护。长时间持有一个派生上下文，可能同时保留父链上的数据；把大请求对象、令牌、完整用户资料塞进值链，会增加不必要的保留和暴露范围。取消上下文不等于立即擦除数据，也不等于对象马上被垃圾回收。

日志只记录完成诊断所必需的关联信息，不输出完整上下文或任意 Value 内容。若已确认真实用户数据被错误返回，应按组织的数据事件流程限制影响并保留必要证据；不要在公开日志中复制敏感样本来证明问题。

每个请求都调用 Background 就能防止泄漏吗？

它不会带来旧父链的值，但也会切断当前请求的取消和截止时间；更无法修复共享缓存或共用对象。对当前请求工作，应保留 r.Context 的关系，在请求内部派生，并修复真正的共享位置。

同一个上下文能给多个协程吗？

可以，但每个协程访问的可变值仍要满足自身的同步与所有权约定。不要在一边读取值对象时，另一边无同步地修改它，更不要把同一对象当作不同用户的私有数据。

修复后建议怎样做回归？

在项目测试中交错发起两组请求，分别检查关联信息与业务资料的归属；增加一个不提供可选值的请求，确认它不会读到前一请求的资料；再检查取消是否能传到下游。可结合竞态检测查数据竞争，但它不能证明没有逻辑串值。以上是建议的测试范围，不是本文已经运行得到的结果。

结论很具体：共享空根通常不是问题，把带请求资料的派生结果或可变对象跨请求复用才是需要追查的边界。这个方案适合普通同步 HTTP 请求链；独立后台任务则需要自己的载荷与生命周期设计。

官方资料

值、父级与取消：https://pkg.go.dev/context

HTTP 请求生命周期：https://pkg.go.dev/net/http#Request.Context

上下文与共享结构设计：https://go.dev/blog/context-and-structs