Context不该存加密Token，而应只存经中间件解密验签后提取的可信业务数据（如userID、role），因Context设计用于传递请求元数据与控制信号，非安全存储通道，存原始或加密Token易致信息泄露、绕过校验及权限失控。
Context里不该存加密Token，而该存解密后的业务数据
直接把加密后的 Token 塞进 context.Context 是常见误区。Context 的设计目标是传递请求生命周期内的**元数据和控制信号**（如超时、取消、trace ID），不是安全存储或传输加密载荷的通道。加密 Token 本质是待验证凭证，必须在进入业务逻辑前完成解密+校验，否则后续所有基于它的鉴权都不可信。
典型错误做法：ctx = context.WithValue(ctx, tokenKey, encryptedToken) —— 这会让下游 handler 被迫重复解密、忽略签名验证、甚至误用过期/篡改数据。
- 加密 Token 应在中间件（如 HTTP handler）中统一解密、验签、解析 claims，并校验
exp、iss等字段 - 只把**可信的业务身份信息**（如
userID、role、scopes）存入 Context，类型建议用自定义 key 避免冲突：type ctxKey string; const userIDKey ctxKey = "user_id" - 绝不把原始加密字符串、密钥、IV 或 base64 编码结果塞进 Context
如何安全地从加密Token提取数据并注入Context
以 JWT 为例，使用 golang-jwt/jwt/v5 解析后存业务字段：
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
tokenStr := r.Header.Get("Authorization")
if tokenStr == "" {
http.Error(w, "missing token", http.StatusUnauthorized)
return
}
// 解密/验签（实际是解析+验证签名）
token, err := jwt.Parse(tokenStr, func(t *jwt.Token) (interface{}, error) {
return []byte(os.Getenv("JWT_SECRET")), nil
})
if err != nil || !token.Valid {
http.Error(w, "invalid token", http.StatusUnauthorized)
return
}
// 从 claims 中提取可信字段
claims, ok := token.Claims.(jwt.MapClaims)
if !ok {
http.Error(w, "invalid claims", http.StatusUnauthorized)
return
}
userID, _ := claims["user_id"].(string)
role, _ := claims["role"].(string)
// 注入 Context：只存解密后的业务数据
ctx := context.WithValue(r.Context(), userIDKey, userID)
ctx = context.WithValue(ctx, roleKey, role)
r = r.WithContext(ctx)
next.ServeHTTP(w, r)
})
}
- 解密和验签必须同步完成，不能只解析不验证（否则攻击者可伪造无签名 payload）
- 用
context.WithValue时，key 必须是**未导出的私有类型**（如type ctxKey string），避免第三方包覆盖 - 如果 Token 使用非对称算法（RSA/ECDSA），
jwt.Parse的 keyfunc 需返回公钥，而非硬编码私钥
为什么用context.WithValue存Token明文也不行
即使你跳过加密步骤，直接把原始 Token 字符串（如 JWT 的三段 base64）塞进 Context，依然危险：
- Token 可能含敏感字段（如邮箱、手机号），Context 可能被日志中间件意外打印，造成信息泄露
- 下游 handler 若误将
ctx.Value(tokenKey)当作已验证凭据直接使用，会绕过过期检查（exp字段未被强制校验） - Context 会被子 goroutine 继承，若 Token 泄露到后台任务中，可能被长期持有，违背最小权限原则
- Go 官方文档明确警告：
context.WithValue仅用于传递“request-scoped data that transits processes and APIs”，不是通用存储桶
需要透传加密Token本身时的替代方案
极少数场景（如网关需转发原始 Token 给下游服务），不应通过 Context，而应显式传递：
- HTTP 请求：用
req.Header.Set("X-Forwarded-Token", encryptedToken)，下游服务自行解析 - gRPC：通过
metadata.MD附加，如md := metadata.Pairs("token", encryptedToken) - 内部 RPC 或消息队列：将加密 Token 作为独立字段写入 payload 结构体，与业务数据分离
- 绝对不要用
context.WithValue透传原始 Token，哪怕加了 “encrypted_” 前缀
真正难的不是怎么塞数据，而是守住「解密和校验必须发生在 Context 注入之前」这条边界——越早验证，越少代码需要信任它。
