echo-jwt/v4 不支持自动刷新，因其仅负责解析、校验和注入claims，不处理续期；需自定义中间件，在exp前30秒签发新token并写入响应头。
不能靠 echo-jwt/v4 自动刷新 —— 它只校验，不续期；必须自己写中间件，在 token 过期前 30 秒内签发新 token 并写入响应头。
为什么 echo-jwt.Config 不提供 Refresh 功能
echo-jwt/v4 的定位是「认证中间件」，不是「会话管理器」。它只做三件事：解析、校验、塞 claims 到 context。exp 字段只用于拒绝过期 token，不会触发重签。你看到的“自动刷新”都是业务层手动实现的，框架本身无此机制。
- 中间件默认返回 401 后就终止请求，根本没机会执行刷新逻辑
-
echojwt.Config.ErrorHandler只能改错误响应，不能拦截校验通过但即将过期的 token - 没有
OnExpiringSoon或BeforeExpire钩子，所有时间判断得自己做
如何在中间件中检测“即将过期”并签发新 token
核心思路：在 echo-jwt 校验通过后，再读一次 claims["exp"]，与当前时间比对。若差值 exp 签一个新 token，并通过 c.Response().Header().Set("X-Token", newToken) 返回。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 必须确保你用的是自定义
NewClaimsFunc（如CustomClaims），否则claims是jwt.MapClaims，类型断言易错 - 别直接复用旧 token 的
Raw字段——要重新调用jwt.NewWithClaims(alg, claims).SignedString(key) - 新
exp建议设为time.Now().Add(24 * time.Hour).Unix()，别简单加 30 秒，避免反复刷 - 刷新逻辑必须放在 echo-jwt 中间件之后，比如：
e.Use(echojwt.WithConfig(...)); e.Use(refreshJWTMiddleware)
刷新时容易踩的坑
刷新不是“换个 token 就完事”，很多细节一错就导致前端收不到或验证失败：
- 响应头名不统一：前端可能期待
Authorization: Bearer xxx，但你写了X-Token→ 前端拿不到，下次请求仍用旧 token - 没处理并发刷新：同一用户多个请求几乎同时触发刷新，可能签出两个新 token，但只有一个生效 → 建议加简单内存锁（如
sync.Map记录 user_id 最近刷新时间） - 旧 token 仍有效：JWT 一旦签出就无法主动作废，只能靠缩短有效期 + 后端维护黑名单（如 Redis 存
jti）来兜底 - 前端没读响应头：很多 Axios/Fetch 示例代码只取
response.data，忽略 headers → 必须让前端明确读response.headers.get("X-Token")并更新本地存储 -
sub字段类型不一致：旧 token 的sub是字符串"123"，而你代码里写成int(claims["sub"].(float64))→ panic，应先fmt.Sprintf("%v", claims["sub"])再转
完整流程该串在哪几个环节
一个可用的刷新链路必须覆盖请求入口到响应出口：
- 前端请求带
Authorization: Bearer old-token - echo-jwt 中间件校验通过，把
*CustomClaims放进c.Get("user") - 你的
refreshJWTMiddleware拿到 claims，算出exp - time.Now().Unix() < 30 - 用相同密钥、相同 payload（仅更新
exp和可选jti）签新 token - 调用
c.Response().Header().Set("X-Token", newToken)，并确保next(c)正常执行 - 前端收到响应后，提取
X-Token，覆盖本地存储中的旧 token
最常被跳过的一步是：没在 refreshJWTMiddleware 里显式调用 next(c)，结果请求卡住无响应。这个中间件不是装饰器，是链式处理器，漏掉就断了。
