是的，忽略jwt.Parse()错误会导致token.Claims类型断言panic或非法请求被放行；必须显式检查err并调用c.AbortWithStatusJSON返回401，且中间件需按业务路径分组注册，避免误拦截/public等免鉴权接口。
中间件里直接调用 jwt.Parse() 会 panic？
是的，jwt.Parse() 返回 error 时若忽略它，后续对 token.Claims 的类型断言（比如转成 jwt.MapClaims 或自定义结构体）大概率 panic；更危险的是，不显式中断流程就调用 next(c)，非法 token 会被放行到业务 handler。必须把错误检查写死在中间件里。
为什么不能只用 jwt.MapClaims 做 Claims 类型？
用 github.com/golang-jwt/jwt/v5 时，ParseWithClaims() 必须传入具体 Claims 类型（如 &MyClaims{}），否则字段取值可能为 nil 或类型断言失败。例如：
type MyClaims struct {
UserID uint `json:"user_id"`
Role string `json:"role"`
jwt.RegisteredClaims
}
// ✅ 正确：传指针，解析后字段可安全访问
token, err := jwt.ParseWithClaims(authStr, &MyClaims{}, keyFunc)
// ❌ 错误：用 jwt.MapClaims 会导致 UserID 取不到或 panic
- Claims 结构体必须嵌入
jwt.RegisteredClaims才能支持过期、签发时间等校验 -
keyFunc应返回*rsa.PublicKey或[]byte，别硬编码密钥字符串 - 若用 HMAC 签名，
keyFunc直接返回[]byte(secret)即可
Token 放 Header 还是 Query？怎么提取才不丢数据？
绝大多数场景走 Authorization: Bearer <token>，但有些 OAuth2 回调（如 Dex）会把 token 放 query 参数里。中间件要兼容两种路径：
- 优先从
c.Request().Header.Get("Authorization")提取，按空格切分取第二段 - fallback 到
c.QueryParam("access_token")，仅限明确设计为 GET 回调的接口（如/oauth/callback） - 千万别混用：
c.FormValue()会触发自动解析 body，破坏原始流，微信/支付宝回调会直接失败 - 提取后记得用
strings.TrimSpace()去首尾空格，避免因空格导致签名比对失败
校验失败后返回 JSON 还是直接 abort？
必须调用 c.AbortWithStatusJSON()，不能只 return c.JSON() 后继续执行 next(c)。前者会终止中间件链，后者仍会进业务 handler。
- HTTP 401 对应未认证（无 token 或格式错），403 对应已认证但权限不足
- 不要依赖
echo.New().Use(middleware.Recover())捕获 JWT 错误——它默认返回 HTML，前端无法解析 - 敏感信息别暴露在错误响应里，比如别返回
"reason": "token expired"，统一用"error": "invalid token"
/public/* 和 /healthz 这类免鉴权路径，如果被 JWT 中间件覆盖，健康检查就会失败。别图省事写 e.Use(JWT)，老老实实用 authGroup := e.Group("/api", JWT)。 
