echo v5 中 middleware.jwt() 已物理删除，必须改用 github.com/labstack/echo-jwt/v4，导入路径含 /v4，调用 echojwt.withconfig() 并正确配置 signingkey、tokenlookup 和 errorhandler。
middleware.JWT() 编译报错或找不到函数
这是 Echo v5 的「物理删除」行为，不是配置问题。v4 的 middleware.JWT() 在 v5 中已彻底移除，连 github.com/labstack/echo/middleware 包都不存在了。
必须改用独立维护的包：github.com/labstack/echo-jwt/v4。安装时漏掉 /v4 后缀（比如只写 go get github.com/labstack/echo-jwt）会拉取错误分支，导致类型不匹配或初始化失败。
常见错误现象：
undefined: middleware.JWTcannot find package "github.com/labstack/echo/middleware"- 运行时报
panic: signing key is nil（因传参方式不对）
正确做法：
- 执行
go get github.com/labstack/echo-jwt/v4 - 导入路径必须是
github.com/labstack/echo-jwt/v4，不是echo/middleware - 不能直接
e.Use(middleware.JWT(...))，要调用echojwt.WithConfig(...)
SigningKey 类型和传值方式容易 panic
SigningKey 字段声明为 interface{}，但实际运行时只接受 []byte 或返回 jwt.Keyfunc 的函数。传 string 会静默失败，中间件启动后一碰 token 就 panic。
HS256 场景下最简安全写法是：
e.Use(echojwt.WithConfig(echojwt.Config{
SigningKey: []byte("your-secret-key"),
}))
若用 RSA 公钥，则必须配合 SigningMethod: jwt.SigningMethodRS256 和 KeyFunc，不能直接塞 *rsa.PublicKey。
另外，ContextKey 默认是 "user"，但如果你后续用 c.Get("user") 却得到 nil，大概率是忘了在 Config 里显式设置它——v4 不再 fallback 到默认值。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
TokenLookup 和 AuthScheme 配置不匹配导致鉴权失效
中间件默认只从 Authorization: Bearer xxx 头读 token。如果前端传的是 Authorization: JWT xxx 或把 token 放 query 参数（如 ?token=xxx），中间件根本不会触发校验逻辑，直接放行或返回 400。
TokenLookup 必须显式指定格式，常见组合：
-
"header:Authorization"（默认，要求 header 存在且格式为Bearer xxx） -
"query:token"（从 URL 查询参数token=...提取） -
"cookie:session_id"（从 cookie 名为session_id的字段提取）
同时注意 AuthScheme：若前端发的是 Authorization: APIKEY abc123，就得设 AuthScheme: "APIKEY"，否则中间件会因前缀不匹配而跳过解析。
400 和 401 混乱，错误响应不可控
echo-jwt/v4 对错误分类非常机械：
- 请求没带
Authorization头 →400 Bad Request - 头存在但格式非法（如少一段、含空格）→
400 - token 格式合法但签名错 / 过期 /
exp超时 →401 Unauthorized
这不符合多数 API 的设计习惯（通常统一返回 401）。想收口成一致状态码，必须用 ErrorHandler 捕获所有 err 并手动响应：
ErrorHandler: func(c echo.Context, err error) error {
return c.JSON(http.StatusUnauthorized, map[string]string{"error": "invalid or expired token"})
},
别依赖默认行为——它不区分“客户端没传”和“token 废了”，而业务上这两者语义完全不同。
最后提醒一句：JWT 的 iat、exp 时间校验依赖服务器本地时间。如果容器或机器时钟偏移超过默认 1 秒容差，token 会无故被拒。上线前务必确认 NTP 同步，或通过 TimeFunc 自定义校验逻辑。
