echo-jwt/v4默认静默失败，不抛panic，验证失败时直接返回401并中断中间件链；需通过Config.ErrorHandler捕获具体错误（如过期、签名无效）并自定义响应。
echo-jwt 中间件默认不抛出异常，失败时直接返回 401
echo-jwt/v4 的设计是“静默失败”：当 token 签名错误、过期、算法不匹配或解析失败时，它不会 panic 或 throw 异常，而是调用 c.NoContent(http.StatusUnauthorized) 并中断后续中间件链。这意味着你写 defer、recover() 或 try-catch 风格的包裹都捕获不到——它根本没走 panic 流程。
常见误判是以为加了 middleware.Recover() 就能兜住 JWT 失败，结果日志里完全没记录，前端只看到空 401 响应。
- JWT 失败属于业务逻辑拒绝，不是运行时 panic
-
middleware.Recover()只捕获panic，对echo.NewHTTPError或直接c.String()无效 - 如果你需要统一记录失败原因（比如 “token expired”、“invalid signature”），必须自己重写错误响应路径
想拿到具体失败原因，得替换 echo-jwt 的 ErrorHandler
echo-jwt 允许你通过 Config.ErrorHandler 注入自定义处理函数，它会在验证失败时被调用，并传入原始 error 和 context。这是唯一能稳定拿到失败细节的位置。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
示例写法：
e.Use(echojwt.WithConfig(echojwt.Config{
KeyFunc: func(c echo.Context) (interface{}, error) {
return []byte(os.Getenv("JWT_SECRET")), nil
},
ErrorHandler: func(c echo.Context, err error) error {
// 此处 err 是 jwt.Parse() 返回的具体错误，如 *jwt.ValidationError
log.Warn("JWT validation failed", "error", err.Error(), "path", c.Request().URL.Path)
switch {
case strings.Contains(err.Error(), "token is expired"):
return echo.NewHTTPError(http.StatusUnauthorized, "token 已过期")
case strings.Contains(err.Error(), "invalid signature"):
return echo.NewHTTPError(http.StatusUnauthorized, "签名无效")
default:
return echo.NewHTTPError(http.StatusUnauthorized, "认证失败")
}
},
}))
- 不要在
ErrorHandler里调用c.JSON()后再 return —— echo-jwt 内部会自动处理响应 - 务必检查
err类型：多数是*jwt.ValidationError，可类型断言后读.Errors位掩码 - 避免在 ErrorHandler 中做耗时操作（如查 DB），它在请求主流程中同步执行
为什么不能靠 defer + recover 捕获 JWT 错误
因为 echo-jwt 的验证逻辑全程无 panic：它用 jwt.ParseWithClaims() 解析，该函数返回 (*, error)，错误分支走的是 if-else 判断 + 提前 return，不是 panic(err)。所以 middleware.Recover() 完全监听不到。
-
middleware.Recover()只对真正 panic 的代码生效（比如空指针解引用、切片越界） - JWT 解析失败属于预期错误流，框架明确归类为 HTTP 错误而非异常
- 若强行在 handler 里包一层
defer/recover，只会捕获你自己写的 panic，和 JWT 无关
生产环境要注意的隐性失败点
有些 JWT 失败根本不会触发 ErrorHandler，比如密钥为空、KeyFunc 返回 nil, nil，这时 echo-jwt 会静默跳过验证，导致未授权访问。这类问题比解析失败更危险，也更难发现。
- 确保
KeyFunc永远不返回(nil, nil)；至少返回(nil, errors.New("missing jwt key")) - 在
ErrorHandler里加一行日志打点，确认它是否真被调用（上线后发现没日志=配置没生效） - 用
docker-http-https-echo工具发几个非法 token 测试端到端响应，别只信单元测试
