直接在handler里写校验逻辑易导致重复代码、错误响应不统一、无短路机制（如漏写return引发panic）、校验分散难维护，且无法提前拦截非法请求破坏“守门人”语义。
为什么直接在 handler 里写校验逻辑容易出问题
Echo 的 echo.Context 提供了 c.QueryParam()、c.FormValue()、c.Param() 等方法，但手动逐个取值、判空、转类型、拼错误信息，会导致重复代码多、错误响应格式不统一、且无法提前拦截非法请求。更关键的是：一旦校验失败，后续中间件或 handler 仍可能被执行，破坏“守门人”语义。
- 校验逻辑分散在多个 handler 中，改一个规则要搜全项目
- 缺少统一的错误结构（比如都返回
{"code":400,"msg":"xxx"}），前端难处理 - 没有短路机制，
c.JSON(400, ...)后没调用return，后续代码照常执行，可能引发 panic 或脏数据
用 echo.MiddlewareFunc 包一层校验器最轻量
不需要引入额外库，直接基于 Echo 原生中间件接口封装。核心是：校验失败时调用 c.JSON() + return，成功则调用 next(c)。
func ValidateQuery(required ...string) echo.MiddlewareFunc {
return func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
for _, key := range required {
if c.QueryParam(key) == "" {
return c.JSON(400, map[string]string{"code": "400", "msg": "missing query param: " + key})
}
}
return next(c)
}
}
}
- 可组合：多个校验中间件按需叠加，如先校验 token，再校验 query，再校验 body
- 不侵入 handler：handler 只管业务，不用关心参数是否存在
- 错误响应由中间件统一控制，避免 handler 里重复写
c.JSON(400, ...)
c.Bind() 和自定义结构体校验的坑
Echo 内置的 c.Bind() 能自动解析 JSON/body 并映射到 struct，但默认不校验字段是否必填，除非你显式加 tag。
- 必须用
validate:"required"这类 tag（需启用echo.Validator） - 默认 validator 是空的，不设
e.Validator = &validator.Validate{}就不会触发 tag 校验 -
c.Bind()失败时返回echo.HTTPError，但错误格式是{"message":"code=400, message=Invalid type..."}，和业务约定的{"code":"400","msg":"..."}不一致
所以推荐这样写：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
type UserReq struct {
Name string `json:"name" validate:"required"`
Email string `json:"email" validate:"required,email"`
}
<p>func BindAndValidate() echo.MiddlewareFunc {
return func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
var req UserReq
if err := c.Bind(&req); err != nil {
return c.JSON(400, map[string]string{"code": "400", "msg": "invalid request body"})
}
if err := validator.New().Struct(req); err != nil {
return c.JSON(400, map[string]string{"code": "400", "msg": "validation failed: " + err.Error()})
}
c.Set("validated_req", req) // 传给 handler 使用
return next(c)
}
}
}</p>路径参数 c.Param() 校验最容易被忽略
c.Param("id") 返回的是 string，但业务中往往需要 int64 或 uuid。如果直接 strconv.ParseInt(c.Param("id"), 10, 64)，失败时 panic 会触发 Echo 默认 500 响应，而不是预期的 400。
- 不要用 defer/recover 捕获，太重，也掩盖真实错误
- 应该在中间件里就做类型转换和范围检查
- 对 UUID 等特殊格式，建议用
uuid.Parse()判断，别靠正则
示例：
func ValidatePathParam(name, pattern string) echo.MiddlewareFunc {
return func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
v := c.Param(name)
if v == "" {
return c.JSON(400, map[string]string{"code": "400", "msg": "path param missing: " + name})
}
if pattern == "int" {
if _, err := strconv.ParseInt(v, 10, 64); err != nil {
return c.JSON(400, map[string]string{"code": "400", "msg": "invalid int path param: " + name})
}
}
return next(c)
}
}
}
中间件链越靠前，越早暴露问题；但也要注意顺序——比如 JWT 校验必须在参数校验之前，否则未授权用户也能触发参数解析逻辑。
