echo-jwt/v4中claims断言必须用jwt.mapclaims，因中间件默认存为jwt.token而非自定义结构体；需先断言jwt.token，再取claims字段转jwt.mapclaims，且exp等时间字段需显式校验。
echo-jwt/v4 中 Claims 类型断言必须用 jwt.MapClaims
echo-jwt/v4 默认把解析后的 Claims 存为 jwt.MapClaims，不是 map[string]interface{} 或自定义结构体。如果你在 handler 里写 c.Get("user").(*MyClaims)，会 panic：类型不匹配。
正确做法是先断言为 *jwt.Token，再取 Claims 字段并转成 jwt.MapClaims：
if user := c.Get("user"); user != nil {
if token, ok := user.(*jwt.Token); ok {
if claims, ok := token.Claims.(jwt.MapClaims); ok {
userID := int(claims["id"].(float64)) // 注意：JSON number 默认是 float64
userName := claims["name"].(string)
}
}
}
- 不要直接对
c.Get("user")做结构体断言，它存的是*jwt.Token，不是 claims 本身 -
jwt.MapClaims是map[string]interface{}的别名，但字段值类型需手动转换（如int、string、bool） - 如果签发时用了自定义 struct（如
type MyClaims struct{ ID int }），必须在echo-jwt.Config.Claims中显式指定，否则中间件仍用默认jwt.MapClaims
自定义 Claims 结构体需要显式传入 Config.Claims
想用强类型访问 claims（比如 claims.ID 而非 claims["id"].(float64)），不能只靠签发时用 struct，还必须让 echo-jwt 中间件“知道”你用的是什么类型。
否则中间件仍按默认 jwt.MapClaims 解析，你的结构体字段会丢失或无法访问。
示例（正确配置）：
type CustomClaims struct {
ID int `json:"id"`
Role string `json:"role"`
jwt.StandardClaims
}
e.Use(echo_middleware.JWTWithConfig(echo_middleware.JWTConfig{
SigningKey: []byte("secret"),
Claims: &CustomClaims{}, // ← 必须传指针，且类型要和签发时一致
}))
-
Claims字段必须是结构体指针，不能是值或 interface{} - 签发时也要用同一结构体：
token := jwt.NewWithClaims(jwt.SigningMethodHS256, &CustomClaims{...}) - 标准字段（
exp,iat,nbf）建议嵌入jwt.StandardClaims，否则时间校验不会自动生效
Claims 中的 exp/nbf/iat 不会自动校验，除非启用 ValidTimeFunc
很多人以为设置了 exp 就能自动拒绝过期 token，其实 echo-jwt/v4 默认只做签名验证，exp 字段存在但不校验——除非你显式启用时间函数。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
错误现象：token 已过期，但 handler 仍能拿到 claims 并执行业务逻辑。
修复方式是在 JWTConfig 中配置 ValidTimeFunc：
ValidTimeFunc: func(t time.Time) bool {
return t.After(time.Now().Add(-time.Second)) // 允许 1 秒误差
}
- 不配
ValidTimeFunc→token.Valid返回 true，即使exp已过 -
ValidTimeFunc接收的是 claims 中解析出的时间（UTC），不是当前时间，需自己比对 - 推荐直接用
claims.VerifyExpiresAt(time.Now(), true)封装，更可靠
从 Claims 读取字段时要注意类型和空值
jwt.MapClaims 里的所有 JSON 值都按原始类型映射：数字是 float64，布尔是 bool，字符串是 string，数组是 []interface{}。直接类型断言失败很常见。
典型错误：claims["id"].(int) → panic，因为 JSON number 总是 float64。
安全读取建议：
- 用
claims["id"].(float64)再转int(claims["id"].(float64)) - 用
fmt.Sscanf或strconv做容错转换（适合可能缺失或类型错乱的字段） - 对可能为空的字段，先检查
_, ok := claims["role"]，避免 panic - 前端传来的
"true"/"false"字符串，需手动解析，不会自动转bool
最易被忽略的是：Claims 字段读取没有默认值、不校验结构、不报错——错类型或空字段只会让你的 handler panic 或逻辑异常，而不会在 JWT 验证阶段暴露问题。
