echo-jwt/v4解析失败会panic，因jwt.ParseWithClaims遇签名错、过期、alg:none等均返回error，忽略err即交由recover兜底，但默认recover不返回JSON；token.Valid为true仍被拒是因未校验aud/iss等业务声明或alg:none。
echo-jwt/v4 解析失败直接 panic，不是配置问题，是没兜住错误。 它底层调用 jwt.ParseWithClaims，任何签名错、过期、alg: none、时间戳单位错都会返回 error；你若写 token, _ := jwt.Parse(...) 忽略它，就等于把 panic 留给 recover 中间件——而 echo 默认 recover 不返回 JSON，前端只收到空响应或 500 页面。
为什么 token.Valid == true 但还是被拒绝？
因为 token.Valid 只检查签名和基础时间字段（exp/nbf/iat），不校验 aud、iss、sub 等业务声明，也不拒绝 alg: none。常见漏点：
-
KeyFunc里没判断token.Header["alg"] == "none"，攻击者可伪造无签名 token - 没传
jwt.WithValidTimeFunc，系统时钟偏差 >1 秒就触发ErrTokenExpired -
exp字段用了毫秒时间戳（如time.Now().UnixMilli()），但 JWT 要求秒级int64 - 签发时设了
aud: "api.example.com"，但验证时没传jwt.ClaimsAudience{"api.example.com"}
如何安全地从 context 提取已解析的 token？
别在中间件里重复调 jwt.ParseWithClaims——echo-jwt 已把结果存进 c.Get("user")，直接类型断言即可：
if user, ok := c.Get("user").(*jwt.Token); ok {
if claims, ok := user.Claims.(jwt.MapClaims); ok {
jti, _ := claims["jti"].(string)
// 后续查 Redis 黑名单
}
}
注意：c.Get("user") 返回的是 interface{}，必须显式断言为 *jwt.Token；如果断言失败，说明 echo-jwt 根本没通过校验，该请求已被拦截。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
WebSocket 接口鉴权失败却没报错？
因为 WebSocket 升级后 c.Request() 失效，所有鉴权必须在 upgrader.Upgrade() 前完成。错误做法：
- 把
echo-jwt中间件挂到e.GET("/ws", handler)上——中间件会先写响应头，导致Upgrade()失败 - 在
upgrader.Upgrade()后再读c.QueryParam("token")——此时c已不可用，返回空或 panic
正确路径：http.HandlerFunc → 提取 query/header 中的 token → 手动验证 → 失败则 return（返回 HTTP 错误）→ 成功才调 upgrader.Upgrade()。
真正难处理的是黑名单写入与查询之间的竞争：用户登出瞬间发新请求，Redis 写入延迟可能导致漏检。用 SET revoked:{jti} "" EX 900 NX 是底线，但得接受它不能 100% 覆盖时钟漂移+网络抖动组合场景。
