echo-jwt/v4 不负责设置 jwt 过期时间，exp 必须在签发时由 jwt.registeredclaims 显式设定；验证阶段需确保服务器时间同步，避免 clockskew 导致误判；刷新令牌应独立实现于路由 handler，而非中间件自动续期。
echo-jwt/v4 中无法直接设置过期时间
你不能在 echo-jwt 中间件里配置 JWT 过期时长——它只负责验证已存在的令牌，不参与签发。过期时间（exp）必须在生成 JWT 时就写入 payload，由签发方（比如登录接口）控制。
常见错误是误以为配置了 echo-jwt 就能“让 token 活多久”，结果发现 token 一直不过期或提前失效，本质是签发逻辑和验证逻辑被混为一谈。
-
echo-jwt的作用：解析 Authorization header、校验签名、检查exp/nbf等标准声明、抛出401或403 - 真正决定过期时间的代码，一定出现在你调用
jwt.Sign()或类似方法的地方（如github.com/golang-jwt/jwt/v5） - 如果你用的是旧版
github.com/dgrijalva/jwt-go，注意它已归档，v5 是当前维护主线
生成 JWT 时设置 expiresIn 的正确姿势
在登录成功后生成 token 的环节，用 jwt.RegisteredClaims 显式传入 ExpiresAt 字段最稳妥，避免字符串解析歧义（比如 "7d" 在某些版本中可能因时区或解析库差异失效）。
import (
"time"
"github.com/golang-jwt/jwt/v5"
)
<p>func generateToken(userID string) (string, error) {
claims := jwt.RegisteredClaims{
Subject: userID,
ExpiresAt: jwt.NewNumericDate(time.Now().Add(30 * time.Minute)),
IssuedAt: jwt.NewNumericDate(time.Now()),
}
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
return token.SignedString([]byte("your-secret"))
}
</p>
- 不要依赖
expiresIn: "30m"这类字符串参数，尤其在生产环境——它依赖第三方库的解析逻辑，且无法做单位校验 -
time.Now().Add(...)必须用本地服务器时间（不是客户端传的时间），否则时钟偏移会导致校验失败 - 如果使用 Redis 存储黑名单或刷新令牌，记得同步清理对应 key 的过期时间，别只改 JWT 里的
exp
验证阶段 ClockSkew 导致“明明没过期却报错”
服务端校验 exp 时，默认允许一定时间偏差（ClockSkew），防止服务器之间时间不同步引发误判。但 Echo 默认不设这个值，而底层 jwt 库（如 v5）默认是 5 秒。如果你的服务器时间比 NTP 慢几秒，刚签发的 token 就可能被拒。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
解决办法是在 echo-jwt 配置里显式关闭或放宽：
e.Use(echojwt.WithConfig(echojwt.Config{
SigningKey: []byte("your-secret"),
ContextKey: "user",
ErrorHandler: func(c echo.Context, err error) error {
return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid or expired token"})
},
// 关键：禁用自动时间容错，强制严格校验
ConfigFunc: func() jwt.ParserOptions {
return jwt.ParserOptions{SkipClaimsValidation: false}
},
}))
- 更推荐做法：统一用 NTP 同步所有服务节点时间，然后设
ClockSkew: 0（需看具体 jwt 库是否支持该字段透传） - 若用
golang-jwt/jwt/v5，它不暴露ClockSkew，而是通过Parser.ValidateExp和time.Now()对比，所以时间一致性更重要 - 调试时可用在线工具解码 token，看
exp值是否符合预期，再比对服务器当前时间戳
刷新令牌（Refresh Token）不能靠中间件自动续期
有人试图在 echo-jwt 中间件里拦截过期 token 并悄悄重签一个新 token 返回，这是危险操作：它绕过了用户主动行为（如点击“保持登录”）、无法审计、且容易造成 token 泛滥。
正确路径是前后端协作的两层 token 架构：
- Access Token：短时效（如 15 分钟），只用于 API 请求，过期即 401
- Refresh Token：长时效（如 7 天），HttpOnly Cookie 存储，仅用于
/auth/refresh接口换新 Access Token - 刷新接口必须校验 Refresh Token 的签名 + DB 黑名单 + 绑定设备/IP（可选），不能只靠 JWT 自带的
exp
这个逻辑必须独立于 echo-jwt，放在专门的路由 handler 里实现，而不是塞进认证中间件。
