echo.context 默认不复用，gc压力上升；须启用对象池、禁用默认logger、避免深拷贝和跨goroutine传递；中间件修改context需透传request；响应统计需用wrapresponsewriter包装器。
echo.Context 默认不复用，GC压力会明显上升
默认情况下，Echo 每次请求都会新建一个 echo.Context 实例，不像 Gin 那样自动从 sync.Pool 中获取复用对象。在 10k+ RPS 场景下，这会导致频繁内存分配，GC 频率升高、STW 时间变长，pprof 可能显示大量 runtime.mallocgc 占比异常。
实操建议：
- 必须显式启用上下文对象池：在
e := echo.New()后立即调用e.Pre(echo.MiddlewareFunc())（注意是Pre，不是Use） - 禁用默认
Logger中间件（它内部会拷贝大量字符串），改用异步日志如zap+echo.WrapResponseWriter包装器记录响应大小 - 避免在 handler 中对
echo.Context做深拷贝或序列化（比如存进 map 或发到 channel），它不是线程安全的
不要跨 goroutine 传递或长期持有 echo.Context
echo.Context 是对象池复用的，生命周期绑定单次 HTTP 请求。一旦 handler 返回，该实例可能被回收并重用于下一个请求——若你把它传给后台 goroutine，极大概率读到脏数据或 panic。
常见错误现象：
- 后台任务中调用
c.Request().Context().Done()突然关闭，但请求还没结束 -
c.Param("id")在 goroutine 中返回空字符串或旧值 - pprof 显示大量
echo.(*context).Reset调用，说明复用逻辑被破坏
正确做法：只在 handler 内部使用；如需异步操作，应派生新 context：ctx, cancel := context.WithTimeout(c.Request().Context(), 3*time.Second)，然后传 ctx（不是 c）给 goroutine，并 defer cancel()。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
中间件里修改 context 必须透传 request 对象
Echo 的中间件签名是 func(echo.Context) error，但底层仍依赖 *http.Request 携带真实 context。如果你在中间件里调用 c.Set("key", val) 或 c.Request().WithContext(newCtx)，却不更新 c.Request，下游 handler 拿到的仍是原始 r.Context()。
关键点：
-
c.Request().Context()是唯一可信入口，所有超时/取消信号都从此发出 - 若手动替换 context（比如注入 traceID），必须执行
c.Request = c.Request.WithContext(newCtx) - 不要用
context.Background()或context.TODO()替代——它们会切断 deadline 和 cancel channel -
echo.Context.Value()底层调的是r.Context().Value()，所以透传 request 才真正生效
ResponseWriter 包装器才能准确获取状态码和响应体大小
c.Response().Status 在 handler 返回前始终为 0；c.Response().Size() 也只在写入完成后才反映真实字节数。想做耗时统计、审计日志或熔断判断，不能直接读这些字段。
实操方案：
- 用
echo.WrapResponseWriter包装原始http.ResponseWriter，在WriteHeader和Write方法里捕获状态码与字节数 - 包装器需注册为 Pre-middleware（在路由匹配前生效），否则可能错过 404 等非 handler 触发的响应
- 注意：包装器本身不能持有
echo.Context引用，否则又引入跨 goroutine 传递风险
Pre() 和 Use() 的调用时机差异，以及 Request.WithContext() 这一步透传动作——没做这两件事，上下文生命周期就断了，后续所有超时控制、trace 透传、资源释放都会失效。
