echo-jwt/v4默认不支持黑名单校验，因其设计为轻量无状态，仅做签名和时间字段验证，不查Redis或DB；需在中间件链中额外添加自定义黑名单检查。
为什么 echo-jwt/v4 默认不支持黑名单校验
因为 echo-jwt/v4 的设计目标是轻量、无状态、只做基础解析和签名验证，它默认不介入业务级的 token 生命周期管理。它会在解析后调用 token.Valid，但这个方法只校验签名、exp/nbf/iat 时间字段，**完全不查 Redis 或 DB**。一旦你把“登出即失效”当成需求，就必须自己补一层拦截逻辑——不是改中间件，而是在它之后加一个自定义中间件。
如何在 echo-jwt 后链式插入黑名单检查
别动 echo-jwt 的配置，直接在它后面注册一个新中间件，从 context 中取出已解析的 token，提取 jti 字段（或 fallback 到 token.Raw），再查黑名单存储：
- 确保签发时设置了
jti：claims["jti"] = uuid.NewString() - 黑名单存储推荐用 Redis，key 为
revoked:{jti}，TTL 设为与 token 的exp对齐（比如 15 分钟） - 检查逻辑要短路：如果
redis.GET revoked:{jti}返回非空，就return echo.NewHTTPError(http.StatusUnauthorized, "token revoked") - 不要在黑名单中间件里重复解析 token——
echo-jwt已把*jwt.Token放进c.Get("user")，直接类型断言即可
ParseWithClaims 里必须显式启用时间校验和算法限制
很多人用 echo-jwt 时只配了密钥，却忘了它底层调用的是 jwt.ParseWithClaims，而这个函数默认行为很危险：
-
exp过期不报错：除非你传jwt.WithValidTimeFunc或手动调token.Claims.(jwt.MapClaims).VerifyExpiresAt -
alg: none可绕过签名：必须在Keyfunc里拒绝token.Header["alg"] == "none" - 时间戳单位错乱：
exp必须是秒级int64，不是毫秒；否则刚签发就"token is expired"
正确写法示例（在 echo-jwt.Config.KeyFunc 中）：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
func(token *jwt.Token) (interface{}, error) {
if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
}
return jwtKey, nil
}
黑名单查不到就放行？小心时钟漂移和并发竞争
看似“查不到就是有效”，但在生产环境这会出问题：
- 服务端时间比客户端快几秒 → token 实际未过期但被拒（加
jwt.WithValidTimeFunc容忍 ±5s 偏差） - 用户刚登出，紧接着发一个带旧 token 的请求 → Redis 写入延迟导致漏检（用 Redis 的
SET revoked:{jti} "" EX 900 NX保证原子性） - 用
token.Raw当 key 而非jti→ 长 token 字符串增加网络和存储开销，且无法做语义化清理
真正难的不是“怎么加黑名单”，而是让黑名单查询本身不拖慢正常请求、不引入单点故障、不因时序问题误判。别把 revoked_jti 表建在主库上，也别用内存 map 存——那只是伪无状态。
