JWT验证失败默认只返回401且不暴露原因，必须配置echojwt.Config.ErrorHandler才能捕获具体错误（如过期、签名无效），因echo-jwt/v4采用静默失败设计，不触发panic，recover()无法捕获。
JWT验证失败时默认只返回401且不暴露原因，必须重写ErrorHandler才能拿到具体错误（如过期、签名无效），靠recover()或中间件包裹完全捕获不到。
为什么recover()对JWT失败无效
echo-jwt/v4的设计是“静默失败”：验证失败时直接调用c.NoContent(http.StatusUnauthorized)并中断中间件链，全程不触发panic。所以middleware.Recover()根本收不到任何异常，日志里也看不到报错。
- 常见误判是以为加了全局
Recover()就能兜住所有错误，结果前端只看到空401响应 -
echo.NewHTTPError、c.JSON()这类显式错误也不会被recover()捕获——它只管panic - JWT失败属于业务逻辑拒绝，不是运行时崩溃，不该用panic机制处理
怎么拿到具体的失败原因（过期/签名无效/alg:none）
唯一可靠路径是配置echojwt.Config.ErrorHandler，它会在验证失败时被调用，并传入原始error和echo.Context。
大模型Token成本节约
下载
大模型 Token 成本节约工具。在请求到达大模型之前自动压缩 prompt 和上下文，减少 60-95% 的 token 消耗，直接降低 API 成本。支持 Claude/OpenAI/Gemini 等主流模型，提供代理模式、CLI 包装、Python SDK 和 MCP Server 四种接入方式。内置一键安...
- 多数错误是
*jwt.ValidationError，可用类型断言后读.Errors位掩码，比字符串匹配更稳 - 别在
ErrorHandler里调c.JSON()后再return——echo-jwt内部会自动处理响应，重复写会panic - 避免在
ErrorHandler中做DB查询或Redis操作，它是同步执行的，会拖慢所有非法请求 - 示例判断：
if errors.Is(err, jwt.ErrTokenExpired)比strings.Contains(err.Error(), "expired")更安全
为什么token.Valid == true但还是被拒
token.Valid只校验签名和基础时间字段（exp/nbf/iat），不检查aud、iss、sub等业务声明，也不拒绝alg: none。
- KeyFunc里没判断
token.Header["alg"] == "none"，攻击者可伪造无签名token -
exp用了毫秒时间戳（time.Now().UnixMilli()），但JWT要求秒级int64 - 签发时设了
aud: "api.example.com"，但验证时没传jwt.ClaimsAudience{"api.example.com"} - 服务器时钟偏差超过1秒，又没配
TimeFunc，导致合法token被判定为过期
WebSocket鉴权失败却没报错？因为升级前就该结束
WebSocket的upgrader.Upgrade()会接管连接并关闭HTTP响应流，之后c.Request()失效，所有鉴权必须在升级前完成。
- 错误做法：把
echojwt挂到e.GET("/ws", handler)上——中间件先写响应头，Upgrade()直接失败 - 错误做法：在
Upgrade()后读c.QueryParam("token")——此时c已不可用，返回空或panic - 正确路径：用
http.HandlerFunc提取query/header中的token → 手动验证 → 失败则return（返回HTTP错误）→ 成功才调upgrader.Upgrade() - 真正难处理的是黑名单竞争：用户登出瞬间发新请求，Redis写入延迟可能导致已登出的token仍被接受
