echo-jwt/v4 解析 token 时必须显式启用时间校验，默认不验证 exp/nbf/iat；需在 KeyFunc 中手动校验过期、阻断 none 算法，并安全断言 c.Get("user") 类型，同时配置 TokenLookup 支持多入口提取。
echo-jwt/v4 解析 token 时必须显式启用时间校验
默认情况下 jwt.ParseWithClaims 不验证 exp/nbf/iat 字段，哪怕 token 已过期也返回 Valid == true。这不是 bug，是 jwt-go 的设计行为——你得自己传 jwt.WithValidTimeFunc 或手动调 VerifyExpiresAt。
在 echo-jwt.Config.KeyFunc 中最稳妥的做法是：解析后立刻校验时间，并拒绝非法算法：
- 检查
token.Header["alg"]是否为"none"，直接 return error 阻断 - 用
claims.VerifyExpiresAt(time.Now().Unix(), true)校验过期（注意单位是秒级int64，不是毫秒） - 若校验失败，return
echo.NewHTTPError(http.StatusUnauthorized, "token expired")，别只抛错不响应
从 Context 安全取出已解析的 token 对象
echo-jwt 解析成功后会把 *jwt.Token 存进 c.Get("user")，但这个值是 interface{} 类型，必须类型断言才能用。很多人直接写 c.Get("user").(*jwt.Token)，一旦中间件没跑完或 key 被覆盖就 panic。
正确做法是加一层安全断言：
TokenGX Cap 验证码【代码集成】技能 —— 面向开发场景，提供前端组件和后端验证的代码模板，帮助用户将 Cap 无感验证码快速集成到网站或应用中。适用场景：注册登录防刷、表单提交保护、API 接口防爬、发短信/邮件防滥用等。支持前端（HTML/React/Vue/Next.js）和后端（Node.js/Python/PHP/Go）全栈集成。触发词：集成验证码、添加人机验证、CAPTCHA 集成、cap widget、验证码前端、验证码后端、防刷表单等。与 tokengx-cap-admin（服务
- 先判断
v, ok := c.Get("user").(*jwt.Token)，!ok就说明 token 没被成功解析，应返回 401 - 再检查
v.Valid == false，即使进了中间件，也可能因时间校验失败而被标记为无效 - 提取 claims 时用
v.Claims.(jwt.MapClaims)，不要硬转结构体，除非你 100% 确保签发时用了对应结构
Token 提取位置不只有 Authorization Header
echo-jwt 默认只从 Authorization: Bearer xxx 提取，但实际场景中 token 可能来自 query 参数（如 ?token=xxx）、cookie（X-JWT-Token），甚至 form data。靠改源码不现实，要用 TokenLookup 配置多入口：
- 设置
TokenLookup: "header:Authorization,query:token,cookie:jwt" - 如果需要更灵活控制（比如只对某些路径开 query 支持），得自定义
TokenLookupFuncs切片，每个函数返回[]string候选 token 字符串 - 注意：多个入口同时存在时，
echo-jwt取第一个非空结果，不会合并或 fallback
解析失败时的错误信息不可信，要自己补日志
echo-jwt 内部捕获错误后只返回泛化的 401 或 400，不透出具体原因（比如是签名错、过期、还是 alg 不支持）。调试时容易卡在“为什么这个 token 就是不行”。
建议在 KeyFunc 或前置中间件里加日志：
- 记录原始 token 前 10 个字符（防泄露）和
c.Request().RemoteAddr - 对
token.ParseWithClaims的 error 做 switch 判断：jwt.ErrSignatureInvalid、jwt.ErrTokenExpired、jwt.ErrInvalidType - 避免在生产环境打全量 token，但至少保留
token.Method.Alg()和token.Header["kid"]辅助排查
解析本身不难，难的是每一步都可能静默失败；尤其是时间校验开关、类型断言安全性和多入口提取逻辑，这三个点漏掉任何一个，都会让 token 表面有效、实际失控。
