Go网关鉴权应优先使用中间件而非独立服务，因其轻量、低延迟、易调试；需统一拦截所有入口路径，用策略模式支持多鉴权方式共存，并避免context.WithValue传用户实体。
鉴权逻辑该放在中间件还是单独服务
Go网关鉴权模块通常不建议做成独立微服务，除非你已明确拆分出统一认证中心且具备强一致性要求。大多数场景下，http.Handler 中间件更轻量、延迟更低、调试更直接。中间件能天然拦截所有请求路径，也方便结合 context.Context 透传用户身份信息。
容易踩的坑是把鉴权逻辑写在路由 handler 内部——这会导致重复代码、遗漏路径、无法统一拒绝响应格式。务必确保所有入口都经过同一层中间件，包括健康检查、指标接口等非业务路径（可配置白名单绕过）。
- 用
func(http.Handler) http.Handler模式封装，避免修改原始 handler 结构 - 拒绝响应统一返回
401 Unauthorized或403 Forbidden，不要混用 - 若需 JWT 解析，优先用
github.com/golang-jwt/jwt/v5而非 v3/v4，v5 对time.Time和时区处理更严谨
JWT token 解析时如何避免常见 panic
jwt.Parse 失败时不会自动 panic，但开发者常因忽略 err 或误判 token.Valid 导致空指针或越权访问。核心问题是：解析成功 ≠ token 有效 ≠ 签名合法 ≠ 未过期 ≠ 在白名单内。
必须按顺序校验：Parse 错误 → Valid 为 false → Claims 类型断言失败 → exp / nbf 时间校验 → 自定义字段（如 iss、aud）匹配。
立即学习“go语言免费学习笔记（深入）”；
- 永远用
jwt.WithValidMethods([]string{jwt.SigningMethodHS256.Name})显式限制算法，防算法混淆攻击 - 不要直接用
token.Claims，先做类型断言：if claims, ok := token.Claims.(jwt.MapClaims); ok { ... } - 时间校验必须调用
claims.VerifyExpiresAt(time.Now().UTC(), true)，注意传入 UTC 时间
如何支持多种鉴权方式共存（API Key + JWT + OAuth2）
真实网关往往要同时支持内部系统用 API Key、前端用 JWT、第三方集成走 OAuth2 introspection。硬编码 if-else 容易失控，推荐用策略模式 + 请求头识别。
关键不是“怎么实现每种方式”，而是“怎么决定用哪一种”。建议依据 Authorization 头前缀或自定义头（如 X-Auth-Type: jwt）路由到对应验证器，各验证器返回统一的 AuthResult 结构体（含 UserID、Scopes、IsAdmin 等字段）。
- API Key 从
X-API-Key读取，查 Redis 缓存（带 TTL），避免每次 DB 查询 - OAuth2 introspection 必须设超时（
ctx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)），并缓存结果（如 5 分钟） - 所有验证器最终都调用同一
enforcePermission(path, method, scopes)做 RBAC 判定，避免权限逻辑散落
为什么 Context.WithValue 不适合传用户身份
用 context.WithValue(r.Context(), key, user) 看似简洁，但极易引发类型错误、key 冲突、内存泄漏（value 不释放）。Go 官方文档明确建议：仅用于传递请求范围的元数据，而非业务实体。
正确做法是定义强类型上下文 key，比如 type userCtxKey struct{}，再用 context.WithValue(r.Context(), userCtxKey{}, &User{...})。但更稳妥的是封装一个 *http.Request 的包装器，或直接在中间件中将用户信息写入 request.Header（只读场景）或自定义结构体字段。
- 绝对不要用
string或int作 context key，否则不同包之间极易覆盖 - 如果下游 handler 需要用户信息，优先通过函数参数传递，而非从 context 取 —— 这让依赖显性化，便于测试和重构
- 鉴权中间件结束前务必检查
user != nil，防止未鉴权请求透传
