JWT过期必须依赖payload中标准exp字段（int64秒级Unix时间戳），由token.Claims.Valid()显式触发校验；推荐用jwt.RegisteredClaims并配置WithClockSkew容错。
JWT过期时间必须写在 exp 字段里，不能靠外部缓存或服务端计时
Go 的 jwt-go（v3 及以前）或 golang-jwt（v4+）都只认标准 Claims 中的 exp 字段来校验过期。你手动记个时间戳、或者用 Redis 存个“预计过期时间”，JWT 库本身不会读它——校验时只看 token payload 里的 exp 值。
常见错误是：生成 token 时没设 exp，以为后续用 time.Now().Add(24 * time.Hour) 就够了；或者写了但用了错的字段名，比如 expires_at 或 timeout，结果 token 永远不报过期。
-
exp必须是 int64 类型的 Unix 时间戳（秒级），不是 time.Time，也不是毫秒 - 用
time.Now().Add(...).Unix()，别用.UnixMilli() - 如果用
golang-jwtv4+，推荐直接用jwt.RegisteredClaims，它内置了ExpiresAt字段，类型是*jwt.NumericDate，需要 wrap 一下：jwt.NewNumericDate(time.Now().Add(24 * time.Hour))
用 jwt.RegisteredClaims 而不是 map[string]interface{} 构建 Claims 更安全
手写 map 构造 Claims 看似灵活，但容易漏字段类型、拼错 key、忘记 exp，而且无法静态检查。尤其 exp、iat、nbf 这些字段，map 里写成字符串或 float64 都会导致解析失败或静默忽略。
示例对比：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
// ❌ 危险：字段名小写、exp 是 float64、没 iat
claims := map[string]interface{}{
"exp": time.Now().Add(24 * time.Hour).Unix(),
"user_id": 123,
}
<p>// ✅ 推荐：类型明确、字段标准、自动处理 exp/iad/nbf
claims := jwt.RegisteredClaims{
ExpiresAt: jwt.NewNumericDate(time.Now().Add(24 * time.Hour)),
IssuedAt: jwt.NewNumericDate(time.Now()),
Subject: "user:123",
}
校验时必须调用 token.Claims.Valid()，否则 exp 不生效
很多人解析 token 后只取 token.Claims 里的字段就完事，比如直接读 claims["user_id"]。但这时 exp 校验根本没触发——Valid() 才是真正执行时间字段比对的入口。
- 即使 token 已过期，
token.Claims依然能正常解出原始数据（payload 是 base64，不加密） - 必须显式调用
token.Claims.(jwt.Claims).Valid()，且检查返回 error 是否为jwt.ErrTokenExpired - 用
golang-jwtv4+ 时，ParseWithClaims第二个参数传&jwt.RegisteredClaims{}，解析后直接断言并调Valid()
时钟偏差（clock skew）要主动处理，特别是跨服务或容器部署
服务器时间不一致很常见：宿主机、Docker 容器、K8s Pod 之间可能差几秒。如果 token 刚好在过期临界点，一个服务说“已过期”，另一个说“还有效”，就会出现非预期的 401。
golang-jwt 提供了 WithClockSkew 选项，默认是 0，意味着零容忍。生产环境建议设为 5～10 秒：
parser := jwt.NewParser(jwt.WithClockSkew(10 * time.Second))
_, token, err := parser.ParseUnverified(tokenString, &jwt.RegisteredClaims{})
// 注意：ParseUnverified 不校验签名，仅用于预检；正式校验仍要用 ParseWithClaims + keyfunc
更稳妥的做法是在验证前统一用 NTP 同步所有服务时间，但 clock skew 是快速兜底手段。
过期逻辑全在 token 自身和解析时的时钟判断里，没有魔法。最容易被忽略的是：你以为 token 过期了，其实只是本地时间快了几秒；或者你忘了调 Valid()，导致过期 token 照样通行。
