JWT校验失败时直接panic是因为忽略error会导致token.Claims类型断言失败或非法请求被放行；必须显式检查err并调用c.AbortWithStatusJSON返回401，且中间件需按业务路径分组注册，避免误拦截/public等免鉴权接口。
JWT校验失败时为什么直接panic？
Echo默认不捕获JWT解析错误，jwt.Parse()遇到签名无效、过期、kid不匹配等都会返回error。如果写成token, _ := jwt.Parse(...)忽略错误，后续调用token.Claims可能panic；更危险的是，没显式c.AbortWithStatusJSON()就继续执行handler，等于放行非法请求。
必须检查err != nil并立即中断流程：
- 用
c.AbortWithStatusJSON(http.StatusUnauthorized, map[string]string{"error": "invalid token"})响应，不调用next(c) - 别依赖全局
echo.New().Use(middleware.Recover())兜底——它默认返回HTML，不是JSON，前端无法解析 - 若用
github.com/golang-jwt/jwt/v5，注意ParseWithClaims需传入具体Claims类型，不能只传jwt.MapClaims，否则字段类型断言易出错
中间件里怎么安全透传用户ID？
用c.Set("user_id", id)看似简单，但拼错key、类型混乱、IDE无提示，上线后debug成本极高。真正可维护的做法是定义强类型context key：
- 声明私有key类型：
type userCtxKey string，常量const userIDKey userCtxKey = "user_id" - 在auth中间件中存值：
c.Set(string(userIDKey), uint64(123)) - 在handler里取值：
if id, ok := c.Get(string(userIDKey)).(uint64); ok { ... }，或封装成GetUserID(c)方法 - 避免用
interface{}或map[string]interface{}存用户信息——结构松散，后续加字段难统一
为什么不能把CORS和JWT中间件全挂顶层Group？
很多人图省事，在e.Group("")上一次性.Use(middleware.CORS(), middleware.JWT())，结果/public路径也强制鉴权，/healthz被CORS头污染，调试时发现某个接口莫名401却查不到中间件触发痕迹。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
立即学习“go语言免费学习笔记（深入）”；
按业务域分组才是可控做法：
-
apiV1 := e.Group("/api/v1")—— 仅这里挂JWT()和RateLimiter() -
public := e.Group("/public")—— 只挂CORS()，不挂鉴权 -
admin := apiV1.Group("/admin", middleware.AdminOnly())—— 权限中间件只挂子Group，不影响普通用户接口 - 版本号必须体现在路径（如
/v1），别用Accept头——CDN、日志、网关都难识别，审计时无法按版本统计风险
c.Bind()和c.Validate()到底校验什么？
这两个函数只做“结构合法”检查，不是业务规则闸门。比如Email string `json:"email" binding:"required,email"`能拦住空值或格式错误的邮箱，但拦不住“该邮箱已被注册”这种DB层冲突。
-
c.Bind()静默跳过未传字段，除非加json:",required"标签；即使加了，也只校验存在性，不校验语义 -
c.Validate()依赖validate:tag，但不支持跨字段（如password和confirm_password比对） - 绑定失败默认返回400 + 字段名
"Email"，建议统一包装为小写key+可读消息，避免暴露内部结构 - 唯一性、状态机流转、权限前置判断等，必须下沉到service层，handler只负责解包+转发，否则耦合严重、单元测试难写
iat和jti，导致Redis黑名单失效；还有就是路径参数c.Param("id")拿到字符串后，直接strconv.Atoi却不检查错误，让400变成500。 
