中间件函数签名必须返回echo.handlerfunc；echo中间件本质是接收echo.context并返回echo.handlerfunc的函数，正确写法为func(next echo.handlerfunc) echo.handlerfunc，内部闭包必须调用next(c)以维持请求链。
中间件函数签名必须返回echo.HandlerFunc
Echo 的中间件本质是函数，接收一个 echo.Context 并返回 echo.HandlerFunc（即 func(echo.Context) error）。写错签名会导致编译失败或 panic，比如误写成 func(echo.Context) 或 func(*echo.Echo)。
正确写法示例：
func MyMiddleware() echo.MiddlewareFunc {
return func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
// 前置逻辑
err := next(c) // 调用后续 handler
// 后置逻辑
return err
}
}
}
- 必须用
echo.MiddlewareFunc类型包装，它等价于func(echo.HandlerFunc) echo.HandlerFunc - 内部闭包里调用
next(c)是关键，漏掉就中断请求链 - 不能直接在闭包外操作
c，因为此时c还未初始化
全局注册 vs 路由组注册：作用域差异明显
注册位置决定中间件生效范围。全局注册（e.Use()）对所有路由生效；路由组注册（group.Use()）只影响该组下的子路由。混淆二者容易导致中间件重复执行或漏执行。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
e.Use(MyMiddleware())：所有路由（包括/health、/api/*）都会经过 -
api := e.Group("/api"); api.Use(AuthMiddleware())：仅/api/xxx路由触发认证 - 若在
e.Use()之后又对某路由调用Use()，中间件会叠加执行——顺序按注册先后，不是按路由定义顺序
中间件中读取请求体需提前调用c.Request().Body并恢复
Echo 默认不缓存请求体，中间件里调用 c.Request().Body 会消耗流，后续 handler 再读就会得到空内容。常见于日志、鉴权、限流等需要解析 body 的场景。
- 必须先用
io.ReadAll(c.Request().Body)读取原始 body - 再用
io.NopCloser(bytes.NewBuffer(bodyBytes))构造新io.ReadCloser替换原 body - 否则下游 handler 的
c.Bind()或c.FormValue()会失败 - 注意内存开销：大文件上传时不建议在中间件里全量读取
错误处理要区分next(c)失败和中间件自身panic
中间件里 next(c) 返回非 nil error 是正常流程（如 handler 主动返回 echo.NewHTTPError(404)），但中间件自身 panic 会导致整个请求崩溃且无响应。必须用 defer/recover 拦截。
- 不要在中间件里直接
panic("xxx")，应统一转为c.NoContent(500)或c.String(500, "...") - 如果依赖外部服务（如 Redis 鉴权），超时或连接失败应返回明确 error，而非让 panic 波及整个链路
- 使用
echo.HTTPError可保留状态码，比裸 error 更利于前端识别
next(c) 之后修改 header，实际已无法发送（response 已写出）；或者在中间件里修改 c.Response() 的 Writer，可能破坏 gzip 等内置中间件行为。这些边界情况，调试时得靠打印 c.Response().Status 和检查 c.Response().Committed 来确认。
