必须显式构造http.server并设置readtimeout、writetimeout、idletimeout，因e.start()等封装使用默认零值超时实例，易致连接堆积、文件描述符耗尽；三者建议均设为30秒，分别控制请求读取、响应写入和keep-alive空闲时长。
必须显式配置 http.Server，e.Start() 不行
直接调用 e.Start(":8080") 会跳过所有超时控制——它底层用的是 Go 标准库默认的 http.Server 实例，ReadTimeout、WriteTimeout、IdleTimeout 全为 0，意味着连接永不超时。线上遇到慢客户端、空闲长连接或恶意扫描时，文件描述符迅速耗尽，进程卡死或 GC 频繁停顿。
- 必须手动构造
http.Server，三个超时建议统一设为30 * time.Second -
ReadTimeout控制从读取请求头开始到读完全部 body 的总时间 -
WriteTimeout控制从写响应头开始到写完全部 body 的总时间 -
IdleTimeout控制两次请求之间最大空闲时间（HTTP/1.1 keep-alive 场景关键） - 别用
e.Logger.Fatal(e.Start())，它会掩盖 panic 原因；应捕获server.ListenAndServe()返回的 error 单独处理
BodyLimit 中间件只管大小，不管时间
很多人以为加了 e.Use(middleware.BodyLimit("50MB")) 就万事大吉，其实它只校验 Content-Length 或分块传输的累计大小，不约束上传耗时。用户上传一个 100MB 文件但网速只有 10KB/s，可能花 3 小时才传完——BodyLimit 早放行了，但 ReadTimeout 会在 30 秒后直接断连，返回 408 Request Timeout。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
BodyLimit是前置过滤，适合防爆破式大体请求（如恶意上传 1GB 垃圾） - 真正控上传时长，靠的是
http.Server.ReadTimeout，不是中间件 - 若需更细粒度（如仅对
/upload路由延长超时），得用自定义中间件 +c.Request().Context()绑定子 context，并在 handler 内检查超时
事务和下游调用超时不能依赖 HTTP 层
HTTP 超时只管“客户端 ↔ Echo 服务”这一段。如果 handler 里调 MySQL、Redis 或另一个微服务，这些操作本身没有自动继承 HTTP 超时——它们会继续跑，直到自己超时或失败，而 Echo 已经提前关闭了 response writer，导致 context canceled 或 write: broken pipe 错误。
- MySQL 事务必须用
context.WithTimeout(c.Request().Context(), 5*time.Second)包一层再传给db.BeginTx() - HTTP 客户端调下游，必须显式设置
http.Client.Timeout或用带 timeout 的ctx调Do() - 别假设 “HTTP 超时 = 全链路超时”，这是最隐蔽的超时漏设点
超时不是设一次就完事——ReadTimeout 和 IdleTimeout 冲突时行为难预测，WriteTimeout 对流式响应（如 SSE、大视频）可能误杀，这些边界情况线上压测才能暴露。
