jwt中间件中ctx.value取不到user_id是因为上下文未传递或key类型不一致；必须用私有key类型、显式调用withcontext()、做类型断言；rbac校验应在api层完成；oauth2负责获取jwt，jwt负责携带和验证身份信息；短生命周期access token+绑定设备的refresh token比黑名单更实用；需严格校验exp/nbf并确保时钟同步。
JWT中间件里为什么ctx.Value取不到user_id
根本不是解析失败，而是上下文没传下去或key类型不一致。Go的context.WithValue是浅拷贝，下游handler用错key或没接收到新context，就必然拿不到值。
- 别用字符串当key：
ctx = context.WithValue(ctx, "user_id", uid)——类型不匹配，运行时断言会panic - 必须定义私有key类型：
type ctxKey string+const userCtxKey ctxKey = "user_id" - 中间件里解析完token后，要显式调用
next.ServeHTTP(w, r.WithContext(ctx))，不能漏掉.WithContext() - 下游handler取值前务必做类型检查：
if uid, ok := ctx.Value(userCtxKey).(string); ok { ... }
RBAC权限校验该放在HTTP handler还是业务逻辑层
必须放在API层（即HTTP handler或gRPC interceptor），越早拦截越安全。业务层只管“能不能做”，不管“该不该做”。
- 在gin或echo的中间件里完成角色→权限映射查询，查出
[]string如{"user:read", "order:write"}，存入context - 每个受保护路由开头加
if !hasPermission(ctx, "admin:delete")，403直接返回，不进业务逻辑 - 权限数据建议缓存在Redis中（key为
perm:<user_id></user_id>），TTL设5分钟；用户角色变更时主动DEL对应key - 避免在每个handler里重复查DB，也别把权限判断逻辑混进service层——那会污染领域模型
OAuth2和JWT在微服务里怎么分工
OAuth2管“怎么拿令牌”，JWT管“令牌里装什么、怎么验”。两者不是替代关系，是流程协作关系。
- 前端调
/oauth/authorize走Authorization Code流程，最终从/oauth/token拿到一个JWT - 这个JWT由认证服务签发，payload里至少含
sub（用户ID）、roles（角色数组）、exp、iss（签发方） - 各业务微服务不对接OAuth2服务器，只用本地密钥验证JWT签名+过期时间——这是无状态鉴权的核心
- 敏感操作（如转账、删账号）需额外校验设备指纹（
user_agent+ip_hash）或要求二次验证，不能只信JWT有效期
JWT吊销机制到底要不要做黑名单
短生命周期access token（比如15分钟）+ refresh token绑定设备/IP，比全局黑名单更实用。Redis里存refresh:<jti></jti>比维护全量access token黑名单成本低得多。
- access token不做吊销——它本就是无状态设计，查黑名单反而破坏性能和可扩展性
- refresh token必须存库，字段包括
jti、user_id、client_ip、user_agent_hash、used_at - 每次用refresh token换新access token时，先校验是否已被使用或IP/User-Agent不匹配
- 用户登出或密码重置时，删掉对应
refresh:前缀的所有key，而不是往黑名单塞一堆access:前缀
exp和nbf必须严格校验，且所有服务时钟要NTP同步；否则一个服务认为token已过期，另一个还认为有效，权限就乱了。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
