echo v5 已彻底移除 middleware.jwt()，必须使用独立包 github.com/labstack/echo-jwt/v4；安装需带 /v4 后缀，导入路径、signingkey 类型、tokenlookup 配置及 errorhandler 返回均须严格匹配规范。
直接用 middleware.JWT() 会编译失败或 panic，因为 Echo v5 已物理删除该函数——不是隐藏，是没了。
为什么 middleware.JWT() 找不到或报错
错误现象：undefined: middleware.JWT 或 cannot find package "github.com/labstack/echo/middleware"。根本原因是：v4 的 middleware 包里本就没有这个函数；v5 更是连整个 middleware 包都重构了，JWT 功能彻底移出核心。
- 必须改用独立包：
github.com/labstack/echo-jwt/v4（注意/v4后缀） - 安装命令必须带版本：
go get github.com/labstack/echo-jwt/v4，不加/v4会拉错分支 - 导入路径写错（比如漏
/v4或拼成echojwt/v4）会导致类型不匹配或找不到符号
echojwt.WithConfig() 必须传 SigningKey，且类型要对
SigningKey 是必填字段，空值或类型错误会在运行时 panic，而不是编译期报错。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- HS256 场景下，必须传
[]byte，传string会编译失败（类型不匹配） - RSA 场景不能直接传公钥字节，得用
KeyFunc+SigningMethod -
ContextKey默认是"user"，如果后续 RBAC 中间件读c.Get("claims")却没设，就会 panic -
NewClaimsFunc推荐显式设置，避免用默认的jwt.MapClaims导致类型断言失败
TokenLookup 和 AuthScheme 配置错位导致中间件不触发
中间件默认只从 Authorization 请求头读 token，若前端实际传的是 query:token 或 cookie:jwt，它根本不会解析——不是验证失败，是压根不执行。
-
TokenLookup必须显式配置为"query:token"或"cookie:jwt"，不能依赖默认值 -
AuthScheme默认是"Bearer"，若前端发Authorization: JWT xxx，需同步改成"JWT" - 大小写敏感：
"bearer"不会被识别，必须是首字母大写的"Bearer" - 空格处理：中间件自动剥离前缀，但若前端传
Authorization: Bearerxxx（无空格），仍会解析失败
鉴权失败返回 400 还是 401？取决于错误类型
echo-jwt/v4 对错误分类很机械，不按语义统一处理：
- 请求头完全没有
Authorization字段 →400 Bad Request -
Authorization: Bearer xxx但 token 格式非法（缺段、含非法字符）→ 也是400 - token 格式合法但签名错 / 过期 /
exp到期 →401 Unauthorized - 想统一返回
401，必须用ErrorHandler捕获所有err并手动返回，不能依赖默认行为
最易被忽略的一点：ErrorHandler 函数里调用 c.JSON() 后，必须 显式 return，否则中间件会继续往下走，可能触发空指针 panic 或重复响应。
