echo自定义中间件必须符合func(next echo.handlerfunc) echo.handlerfunc签名，显式调用next(c)才能链式执行；漏调则请求卡死。需注意body读取、注册层级、panic捕获等关键细节。
自定义中间件在 Echo 中不是“加个装饰器”就能完事的，它必须符合 echo.HandlerFunc 的签名，并显式调用 next(c) 才能链式执行后续逻辑；漏掉这一步，请求就卡死在中间件里了。
中间件函数签名和基本结构
Echo 的中间件本质是一个接收 handler、返回新 handler 的闭包。它的类型是 func(echo.Context) error，但你不能直接写一个裸函数注册，必须包装成符合框架约定的形式。
- 必须接收
next echo.HandlerFunc参数，这是下一个中间件或最终路由 handler 的引用 - 必须返回一个新的
echo.HandlerFunc，不能直接返回 error 或 void - 必须在适当位置调用
next(c)，否则后续逻辑（包括你的路由函数）永远不会执行 - 如果想提前终止流程（比如鉴权失败），应直接 return 一个 error，如
c.JSON(http.StatusUnauthorized, ...)
如何在中间件中安全读取请求体
直接调用 c.Request().Body 会消耗一次 body 流，后续 handler 再读就拿不到数据——这是最常踩的坑之一。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 要用
c.Request().Body前，先调用c.Request().ParseForm()或c.Request().ParseMultipartForm()（对文件上传） - 若需多次读取（比如日志 + 鉴权 + 路由处理），得用
c.Request().GetBody()获取可重放的 body 源，再手动重置：c.Request().Body = ioutil.NopCloser(bytes.NewReader(bodyBytes)) - 更稳妥的做法：只在必要中间件里读 body（如签名验证），其余地方靠
c.Bind()在 handler 层解析，避免重复读取
中间件作用域与注册时机差异
中间件是否生效，取决于你把它挂在哪一级：全局 e.Use()、分组 group.Use() 还是单个路由 e.GET(..., middleware, handler)。它们不共享状态，也不自动继承父级配置。
-
e.Use(mw)：影响所有后续注册的路由（包括之后e.Group()里的），但不作用于e.Pre()注册的前置中间件 -
group.Use(mw)：只对该 group 及其子 group 生效；子 group 可调用subgroup.Use()覆盖或追加，不会影响父 group - 路由级中间件（如
e.GET("/api", mw1, mw2, handler)）：仅对该路由生效，优先级最高，且顺序严格按参数排列 - 注意：
e.Pre()是前置中间件（如重定向、HTTPS 强制跳转），它在路由匹配前执行，无法访问c.Param()等路由变量
中间件内 panic 的捕获与日志透出
Echo 默认不捕获中间件内的 panic，一旦发生就会导致整个请求 goroutine 崩溃——除非你显式注册了 middleware.Recover()。
-
middleware.Recover()必须放在e.Use()链的最前面，才能兜住所有后续中间件和 handler 的 panic - 它默认只打印 panic 到 logger，不返回错误响应；如需返回统一 JSON 错误，要配合自定义
HTTPErrorHandler - 不要在中间件里用
defer/recover自己捕获 panic——这会绕过Recover()的统一处理机制，也容易漏掉 goroutine 泄漏 - 调试时可在中间件开头加
fmt.Printf("in %s\n", "your-middleware-name")，确认执行顺序是否符合预期
真正麻烦的从来不是写一个中间件函数，而是搞清它在哪一层生效、body 被谁读过了、panic 有没有被兜住、以及 next(c) 到底有没有被调用——这些细节不盯紧，线上就容易出现静默失败或超时堆积。
