echo.Context不能跨goroutine长期持有，因其生命周期绑定单次HTTP请求，handler返回后可能被对象池复用；正确做法是仅传递必要字段或基于c.Request().Context()派生子context。
echo.Context 不能跨 goroutine 长期持有
echo.Context 是对象池复用的，生命周期绑定到单次 HTTP 请求的 handler 执行周期。一旦 handler 返回，该 c 实例可能被回收并复用于其他请求。
常见错误现象：在 handler 中启动 goroutine 并直接传入 c，后续调用 c.JSON() 或 c.Request().Context() 时 panic 或返回脏数据。
- 正确做法是只传必要字段（如
c.Param("id")、c.QueryParam("page")），或显式拷贝需用的数据到新结构体 - 若需传递上下文，应使用
c.Request().Context()创建子 context（如ctx, cancel := context.WithTimeout(c.Request().Context(), 5*time.Second)），而非传c本身 - 禁止对
c做指针保存、全局 map 缓存、或塞进 channel 后异步消费
中间件里启动 goroutine 必须管控生命周期
中间件执行顺序固定，但其中启动的 goroutine 不受框架调度约束。若中间件 A 启动 goroutine 处理日志/审计，而 handler 因超时提前返回，该 goroutine 可能仍在运行并尝试访问已失效的 c 或关闭的 response writer。
使用场景：鉴权后异步上报行为日志、限流统计聚合、慢请求告警等。
- 所有中间件内启动的 goroutine，必须基于
c.Request().Context()派生，并监听其 Done() 信号及时退出 - 避免在中间件里直接调用
c.String()等写响应方法——中间件不负责响应，只做前置处理 - 若需异步操作结果影响响应（如动态修改 header），改用同步方式或提前在 handler 中完成
并发读写共享状态必须加锁或用 sync.Map
Echo 本身不提供应用级状态管理。开发者常把计数器、缓存 map、配置快照等放在包变量或结构体字段中，多 goroutine 并发读写时触发 data race。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
错误现象：fatal error: concurrent map writes、计数器值异常、cache miss 率飙升。
- 高频读+低频写的场景，优先用
sync.RWMutex保护 map，读用RLock()，写用Lock() - 纯 key-value 缓存且 key 类型为 string/interface{}，直接用
sync.Map，它比加锁 map 更适合高并发读 - 不要依赖 echo.Context.Value() 存储可变状态——它只是线程局部存储，不解决跨 goroutine 共享问题
HTTP server 的 ReadHeaderTimeout 和 IdleTimeout 必须显式设置
Go 默认的 http.Server 配置没有连接空闲超时，长连接堆积会耗尽文件描述符；未设 ReadHeaderTimeout 则恶意客户端可发送半截 header 卡住 worker goroutine。
性能影响：连接数飙高时，goroutine 数量线性增长，GC 压力陡增，P99 延迟跳变。
- 务必在
http.Server初始化时设置：ReadHeaderTimeout: 5 * time.Second、IdleTimeout: 30 * time.Second、WriteTimeout: 10 * time.Second - Echo 不封装 server 配置，所以不能只调
e.Start()，要手写http.Server{Addr: ":8080", Handler: e, ...}.ListenAndServe() - 结合
runtime.GOMAXPROCS与 CPU 核数匹配，避免 goroutine 调度争抢（尤其在容器环境）
真正难的不是写并发逻辑，而是判断哪部分状态必须隔离、哪部分可以共享、以及何时该让 goroutine 主动退场。这些边界在压测前往往看不见，一到流量高峰就暴露。
