应直接使用 echo-jwt/v4 而非手写解析或 BasicAuth，因其内置标准验证、密钥轮换、错误映射和上下文注入；手写易漏 aud/iss 校验、时钟偏移处理及 claims 注入。
直接用 echo-jwt/v4，别自己手写解析逻辑——它已内置标准 JWT 验证流程、密钥轮换支持、错误映射和上下文注入，手写容易漏掉 aud、iss 校验或时钟偏移处理。
为什么不能直接用 BasicAuth 或裸写中间件校验 Token
因为 BasicAuth 只处理 Authorization: Basic base64(user:pass)，而 Token（如 Bearer）是完全不同的协议；裸写中间件则常犯以下错误：
- 没检查
Authorization头格式，比如忽略空格、大小写（"bearer"vs"Bearer"） - 没剥离
"Bearer "前缀，导致解析失败 - 没设置
TimeFunc处理服务器时钟偏差，Token 看似过期但实际有效 - 没把解析后的 claims 注入
c.Get("user")或类似位置，后续 handler 只能重复解析
echo-jwt/v4 的正确初始化方式
安装后，必须显式传入 SigningKey 和可选的 ContextKey，否则运行时报 nil key panic：
import "github.com/labstack/echo-jwt/v4"
e := echo.New()
e.Use(echojwt.WithConfig(echojwt.Config{
SigningKey: []byte("your-secret-key"),
ContextKey: "user", // 解析后 claims 存入 c.Get("user")
ErrorHandler: func(c echo.Context, err error) error {
return c.JSON(401, map[string]string{"error": "invalid token"})
},
}))
注意：SigningKey 类型必须是 []byte，传 string 会编译失败；若用 RSA 公钥，需改用 SigningMethod + KeyFunc。
自定义 claims 并安全提取用户 ID
默认解析的 jwt.MapClaims 是 map[string]interface{}，类型不安全。推荐定义结构体并用 ParseWithClaims：
type CustomClaims struct {
UserID uint `json:"user_id"`
Role string `json:"role"`
jwt.StandardClaims
}
config := echojwt.Config{
SigningKey: []byte("secret"),
NewClaimsFunc: func() jwt.Claims {
return new(CustomClaims)
},
ContextKey: "user",
}
e.Use(echojwt.WithConfig(config))
之后在 handler 中可安全断言：
claims := c.Get("user").(*CustomClaims)
userID := claims.UserID // 不再需要 type switch 或 interface{} 转换
这个步骤常被跳过，导致后续代码满屏 if v, ok := c.Get("user").(jwt.MapClaims); ok { ... }，既啰嗦又易 panic。
最易被忽略的是：JWT 中间件默认只校验签名和有效期，不校验 aud（受众）和 iss（签发者）。如果 API 是多租户或对接第三方 OAuth2 提供方，必须手动在 NewClaimsFunc 返回的 claims 上加验证逻辑，或在 ErrorHandler 里补充检查——否则攻击者可复用其他系统的 Token 绕过鉴权。
