JWT验证中间件取不到user_id的根本原因是context.WithValue未正确传递或key类型不匹配，应定义私有ctxKey类型并用同一key存取；gorilla/sessions不适用于微服务，推荐JWT或opaque token+中央鉴权；RBAC必须在API层拦截；防JWT横向越权需绑定设备指纹、短时access token+单次refresh token、敏感操作二次验证，并权衡黑名单机制。
JWT 验证中间件为什么总在 ctx 里取不到 user_id
根本原因不是解析失败，而是中间件没把解析结果写回 context.Context，或者下游 handler 没用对 key。Go 的 context.WithValue 是只读传递，必须用同一个 interface{} 类型的 key 才能取到值。
- 别用字符串当 key：
ctx = context.WithValue(ctx, "user_id", uid)—— 这会导致取值时类型不匹配，推荐定义私有类型：type ctxKey string const userCtxKey ctxKey = "user_id"
- 中间件里解析完 JWT 后，务必用
next.ServeHTTP(w, r.WithContext(ctx))传入新上下文，而不是直接调用next.ServeHTTP(w, r) - 下游 handler 中用
uid := ctx.Value(userCtxKey).(string)取值前，先做类型断言检查，避免 panic
gorilla/sessions 在微服务中是否还适用
不适用。它依赖服务器端 session 存储（如内存、Redis），天然违背微服务无状态设计原则；且无法跨语言服务共享，一旦网关或认证服务用 Go 写、业务服务用 Java，session 就断了。
- 替代方案是统一用 JWT 或 opaque token + 中央鉴权服务（如 OAuth2 Introspection Endpoint）
- 如果非要用 session，必须所有服务共用同一套 Redis 实例，并确保
gorilla/sessions的Options（如HttpOnly、Secure、SameSite）在所有服务中严格一致 - 注意：默认内存存储仅用于开发，上线必须显式配置 store，否则重启后所有 session 丢失
RBAC 权限检查该放在 API 层还是业务层
必须放在 API 层（即 HTTP handler 或 gRPC interceptor），越早拦截越安全。业务逻辑层只管“能不能做”，不管“该不该做”；权限判断属于访问控制，不是领域逻辑。
- gRPC 场景下，在
UnaryServerInterceptor中解析 token 并调用CheckPermission("user:delete", userID)，拒绝则直接返回status.Error(codes.PermissionDenied, "...") - HTTP 场景下，用中间件统一校验，路径和方法映射成权限标识（如
POST /v1/users → user:create），避免在每个 handler 里重复写if !hasPerm(...) - 权限数据建议缓存（如 TTL 5 分钟的 Redis hash），但注意：用户角色变更后需主动清缓存，不能只依赖过期
如何防止 JWT 被盗用后的横向越权
单靠签名验证不够。攻击者拿到有效 token 后，只要没过期就能一直用——这是 JWT 最常被忽略的风险点。
立即学习“go语言免费学习笔记（深入）”；
- 强制绑定设备指纹：签发时存
user_agent + ip_hash到 token 的custom_claims，每次验证时比对，不一致则拒访 - 引入短期 token + 长期 refresh token 机制：access token TTL ≤ 15 分钟，refresh token 单次使用即失效并生成新 pair，且绑定 device_id
- 敏感操作（如改密码、删账号）必须二次验证：要求提供 MFA code 或重新输密码，不能仅凭当前 JWT 授权
真正难的是 token 状态管理——JWT 本身无吊销能力。如果业务对实时性要求高（比如管理员踢人要秒生效），就得加一层 token 黑名单（如 Redis Set），但会牺牲性能和无状态性。这时候得权衡：是接受短时间窗口风险，还是接受中心化状态依赖。
