echo-jwt/v4默认仅解析结构、校验签名、检查exp/nbf/iat时间字段，不查Redis或数据库，登出后token仍有效直至过期；SigningKey需与签发一致且类型匹配，时间按秒级int64解析，alg为"none"时默认跳过签名验证，TokenLookup配置错误会导致认证逻辑被跳过，错误响应码依解析阶段而定，黑名单需额外中间件实现。
echo-jwt/v4 默认怎么验证 token
它只做三件事：解析结构、校验签名、检查 exp/nbf/iat 时间字段。不查 Redis，不读数据库，也不管你有没有登出——只要签名对、时间没过期，就放行。
这意味着如果你用默认配置，用户点“退出登录”后 token 依然有效，直到自然过期。这不是 bug，是设计使然：echo-jwt/v4 定位就是轻量无状态校验器。
-
SigningKey必须和签发时一致，且类型要匹配（比如 HMAC 就得用[]byte，RSA 就得用*rsa.PrivateKey） - 时间字段默认按秒级
int64解析，传毫秒会直接判定为“已过期” - 如果 token header 中
alg是"none"，默认会跳过签名验证——必须在KeyFunc里显式拒绝
TokenLookup 配置错会导致中间件完全不触发
echo-jwt 默认只从 header:Authorization 读 token，格式必须是 Bearer xxx。如果你前端传的是 query:token=xxx 或 cookie:jwt=xxx，中间件压根不会去解析，直接跳过认证逻辑。
常见错误是改了前端传法但忘了配 TokenLookup，结果所有接口都“免密通行”。
- 查 query 参数：
TokenLookup: "query:token" - 查 cookie：
TokenLookup: "cookie:jwt" - 支持多位置 fallback（v4.10+）：
TokenLookup: "header:Authorization|query:token|cookie:jwt" - 注意大小写：
query:token不等于query:Token
鉴权失败返回 400 还是 401？取决于哪一步出问题
echo-jwt 的错误分类非常机械，不看业务上下文，只看请求层面有没有“尝试提供 token”：
- 请求头完全没有
Authorization字段 →400 Bad Request（它认为这是客户端调用错误） - 有
Authorization: Bearer xxx，但xxx格式非法（少一段、含空格、非 Base64）→ 也是400 - 格式合法，但签名错 /
exp已过 /nbf还没到 →401 Unauthorized
想统一返回 401？不能靠改配置，得用 ErrorHandler 捕获所有错误并重写响应。
如何加黑名单（登出即失效）
echo-jwt 本身不支持黑名单，必须自己加一层中间件，放在 echojwt.WithConfig(...) 之后。
关键不是“怎么查 Redis”，而是“怎么避免重复解析、时钟漂移、并发漏检”：
- 签发时必须带
jti字段：claims["jti"] = uuid.NewString() - 黑名单 key 推荐用
revoked:{jti}，TTL 和 token 的exp对齐 - 查 Redis 前先从 context 取
c.Get("user")，断言成*jwt.Token，别再调ParseWithClaims - 写入黑名单要用
SET revoked:{jti} "" EX 900 NX，防止并发登出覆盖 - 服务端时间若比客户端快几秒，
exp判定可能误杀——在KeyFunc里加jwt.WithValidTimeFunc容忍 ±5s 偏差
最易被忽略的点：黑名单中间件必须紧接在 echo-jwt 之后，顺序错了就取不到已解析的 token；还有，别在中间件里手动调 c.Request().Header.Get("Authorization") 再 parse 一遍——那是重复劳动，也容易绕过时间校验逻辑。
