中间件中需从请求头或cookie提取authorization字段（格式为bearer xxx），校验其存在性、前缀及token有效性，再验证jwt的exp和nbf；刷新逻辑应置于中间件，仅当exp在5–15分钟内过期时触发，通过请求级缓存避免并发重复签发，并在失败时调用c.abortwithstatusjson(401)终止流程。
中间件里怎么拿到并验证旧Token
必须从请求头或 Cookie 中提取 Authorization 字段（格式通常是 Bearer xxx），不能依赖 session 或本地存储。Echo 的 c.Request().Header.Get("Authorization") 是最直接方式，但要注意空值和格式错误——比如字段缺失、前缀不匹配、token 为空字符串。验证时别只做 JWT 签名检查，还得校验 exp（是否过期）和 nbf（是否未生效），否则可能把已失效的 token 当作可刷新依据。
刷新逻辑该放在中间件还是 handler 里
放在中间件里更合理，但必须严格控制触发条件：仅当原 token 的 exp 在未来 5–15 分钟内过期，且业务允许自动续期时才执行刷新。用 time.Until(expTime) 判断比硬编码时间戳更可靠。刷新成功后，新 token 要通过 c.Response().Header().Set("X-Auth-Token", newToken) 返回，而不是覆盖原 header；客户端需主动读取该 header 并更新本地存储。不建议在中间件里直接调用 c.SetCookie()，因为 Cookie 的 HttpOnly 属性会让前端无法读取新 token，破坏无状态设计。
怎么避免并发刷新导致重复发号
多个请求几乎同时到达、都触发刷新时，可能生成多个新 token，造成资源浪费甚至短时双 token 有效。解决方法不是加全局锁（会阻塞整个中间件），而是用请求级缓存 + 原子操作：在 c.Set("refreshed_token", token) 前先查 c.Get("refreshed_token")；若已存在则复用，否则调用 JWT 签发逻辑。注意不要把 token 存到 context 以外的地方（如全局 map），否则会引发 goroutine 安全问题。另外，签发新 token 时务必重置 exp（比如 +24h），但不要延长原 iat 或修改 jti，否则无法追踪 token 生命周期。
为什么不能在 Refresh 中间件里直接调用 c.Next()
因为 c.Next() 会继续执行后续中间件和 handler，而刷新 token 属于前置决策行为——如果刷新失败（比如密钥轮换导致验签失败、Redis 黑名单命中），应该立即返回 401，而不是让请求继续往下走。常见错误是写成 if needRefresh { doRefresh(); c.Next() }，结果刷新出错后 handler 仍被执行。正确做法是：刷新成功则设置新 token 并继续；失败则调用 c.AbortWithStatusJSON(401, ...) 并 return。另外，别在刷新流程中修改 c.Request().Header，Echo 的 request 是只读的，强行改会导致不可预测的 header 同步问题。
