echo-jwt/v4中间件必须显式传入KeyFunc，否则panic；需根据alg动态返回密钥、校验算法白名单、明确TokenLookup位置，并在网关层统一鉴权，下游服务只读可信header。
echo-jwt/v4 中间件必须显式传入 KeyFunc，不能省略
直接用 echojwt.JWT([]byte("secret")) 会 panic —— v4 版本已强制要求提供 KeyFunc，否则无法完成签名验证。这不是可选项，是解析流程的硬性前提。
常见错误写法是把密钥写死在回调里，比如：
func(token *jwt.Token) (interface{}, error) {
return []byte("my-secret"), nil
}
这会导致无法支持 RS256、alg=none 攻击防护缺失、密钥轮换困难。正确做法是根据 token.Header["alg"] 动态返回密钥：
- 若
alg == "HS256"，返回对称密钥（仅限内网可信服务） - 若
alg == "RS256"，从本地public.pem加载公钥（推荐用于生产） - 务必校验
token.Header["alg"]是否在白名单中，拒绝"none"算法
Token 提取位置要明确指定，别依赖默认行为
echo-jwt 默认只从 Authorization: Bearer <token> 头读取，但前端若把 Token 存在 HttpOnly Cookie（更安全），中间件就完全拿不到 —— 它不会自动 fallback 到 Cookie 或 Query。
立即学习“go语言免费学习笔记（深入）”；
必须显式配置提取方式，例如：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
e.Use(echojwt.WithConfig(echojwt.Config{
SigningKey: []byte("..."),
ContextKey: "user",
TokenLookup: "cookie:auth_token", // 或 "header:Authorization"
AuthScheme: "Bearer",
}))
-
TokenLookup支持"header:Key"、"query:token"、"cookie:Name"三种格式，不支持组合 - 若同时支持 Header 和 Cookie，需自己写前置中间件统一提取后塞进固定 header（如
X-Raw-Token），再让 echo-jwt 读它 - Cookie 模式下必须配
Secure: true和SameSite: http.SameSiteStrictMode（HTTPS 环境）
鉴权后必须注入 context，但别直接存原始 token
echo-jwt 解析成功后，会把 *jwt.Token 和 claims 写入 c.Get(config.ContextKey)（默认 key 是 "user"）。但下游 handler 如果直接用 c.Get("user").(*jwt.Token)，就可能意外把原始 JWT 泄露到日志或 debug 接口里。
更安全的做法是：在 echo-jwt 后叠加一层自定义中间件，只提取必要字段并重写 context：
- 从
c.Get("user")取出 claims，断言为jwt.MapClaims - 只提取
user_id、role、perms等业务字段，构造轻量结构体 - 用
c.Set("user_id", uid)或context.WithValue(c.Request().Context(), key, val)注入 - 绝对不要把
*jwt.Token或原始字符串存进 context —— 它不是业务数据，是认证凭证
微服务场景下禁止下游服务自行调用 jwt.ParseWithClaims
如果你的 Echo 服务是网关之后的内部服务（如 user-service、order-service），它收到的请求已经过网关鉴权，此时再自己调用 jwt.ParseWithClaims 就是重复劳动，且带来三重风险：
- 密钥散落：每个服务都硬编码或配置相同密钥，一处泄露全盘失效
- 校验不一致：A 服务忽略
aud，B 服务强制校验，导致权限绕过 - 黑名单失效：Redis 吊销检查变成多点并发查，竞态 + 性能瓶颈
正确姿势是：网关层（Kong/Traefik/自研 Go 网关）完成一次 jwt.ParseWithClaims，验证通过后注入可信 header，如 X-User-ID、X-Roles、X-Auth-Issuer；下游 Echo 服务只读这些 header，不做任何 Token 解析。
这个边界一旦模糊，JWT 鉴权就从“集中管控”退化成“各自为政”，安全水位会断崖式下降 —— 尤其当团队开始接入新服务时，最容易在这里漏掉约束。
