echo-jwt/v4 不拦截空 token 是因 jwt.ParseWithClaims 仅对非空字符串执行解析，空值时中间件静默放行；需在它之前手动按 TokenLookup 规则提取并校验 token 是否存在，否则请求挂起。
客户端没带 JWT 时，echo-jwt/v4 默认不报错、不返回、也不放行——请求会卡在中间件里，fetch 长期 pending，浏览器控制台看不到错误，后端日志也沉默。这不是 bug，是它默认只处理“有 token 但验不过”的情况，对空输入直接跳过校验逻辑。
为什么 echo-jwt 不拦截空 token
echo-jwt/v4 的底层是 jwt.ParseWithClaims，它只在传入非空字符串 token 时才执行解析；如果从 Authorization 头、cookie 或 query 中读不到有效值，中间件就默默往下走，既不调 ErrorHandler，也不设 ContextKey。结果就是后续 handler 里 c.Get("user") 是 nil，而你又没做空值判断，整个响应流就挂住了。
TokenLookup 配置必须匹配前端传法
常见错误是前端把 token 放在 Cookie: jwt=xxx，但中间件还用默认的 "header:Authorization"，导致根本读不到 token，却误以为“token 无效”。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 前端传
Authorization: Bearer xxx→ 配置TokenLookup: "header:Authorization" - 前端传
Cookie: token=xxx→ 配置TokenLookup: "cookie:token" - 前端传
?token=xxx→ 配置TokenLookup: "query:token" - 多个位置都要支持？得自己写包装中间件，
echo-jwt不支持 fallback 链式查找
必须加一层前置校验中间件
不能指望 echo-jwt 拦住空 token，得在它前面或后面补一手显式检查。推荐放在 echo-jwt 前面，提前截断：
- 检查
c.Get("user") == nil不可靠——因为echo-jwt在 token 为空时根本不会往 context 写"user" - 正确做法：按
TokenLookup规则手动取一次，比如c.Cookie("token")或c.Request().Header.Get("Authorization") - 若取到空值或格式不对（如
"Bearer "），直接return c.NoContent(http.StatusUnauthorized)或c.JSON - 别用
echo.NewHTTPError包裹空 token 场景——它只在解析失败时触发，对“没 token”无效
ErrorHandler 只对解析失败生效，不是万能兜底
ErrorHandler 函数只在 jwt.ParseWithClaims 报错时调用，比如签名错、exp 过期、alg 不支持。它**不会**被空 token、缺失 header、cookie 不存在等情况触发。
- 所以不要在
ErrorHandler里写“token 未提供”逻辑，那部分永远执行不到 - 真正要覆盖的边界是：
token.Raw == ""、len(token.Header) == 0、token.Claims == nil—— 这些得在自定义中间件里手动判 - 如果用了
WithValidTimeFunc，注意它只影响时间校验，不影响 token 是否存在的判断
空 token 是最常被忽略的路径，但线上一旦出现，前端 fetch 就静默卡死，监控难捕获。务必在 echo-jwt 前加一道“有没有 token”的硬检查，而不是等它去解析。
