echo.file() 是大文件流式传输的默认安全选择，它支持分块、断点续传和条件请求，但需校验路径防遍历，且不可手动设 content-length；sse 需手动写头、状态码并及时 flush；上传进度须在 multipart 解析前介入原始 body 流；流式场景应主动检测连接状态而非依赖 context.done()。
echo.File() 是大文件流式传输的默认安全选择
直接用 e.Static() 托管视频、日志或导出包，50MB 以上大概率触发连接中断或内存暴涨。它底层走 http.FileServer，不做分块、不支持 Range 请求、也不处理超时缓冲策略。
实操建议：
- 用
c.File(filepath)替代e.Static()：它基于http.ServeFile+io.Copy，天然支持 chunked 编码、断点续传和条件请求（If-Modified-Since/ETag） - 路径校验必须做：检查
filename是否含".."或以"."开头，否则可能被用于路径遍历 - 不要手动设置
Content-Length：Echo v4.12+ 会自动推断并写入头部；显式设置错误值反而导致浏览器解析失败
Server-Sent Events 必须手动控制 flush 和响应头
默认 c.String() 或 c.JSON() 会等 handler 返回才发响应头+内容，而 SSE 要求 header 立即发出、每个 data: 后立刻 Flush()，否则浏览器卡住或报 ERR_INVALID_CHUNKED_ENCODING。
实操建议：
- 先设头：
c.Response().Header().Set("Content-Type", "text/event-stream")、Cache-Control: no-cache、Connection: keep-alive - 必须调用
c.Response().Writer.WriteHeader(http.StatusOK)，不能依赖 Echo 自动写状态 - 用
rw := c.Response().Writer断言为http.Flusher，每次写完完整事件（data: ...\n\n）后立即rw.(http.Flusher).Flush() - 每 20 秒发一次心跳
:\n\n，仅靠retry:字段无法防代理层超时断连
上传进度追踪需在 multipart 解析前介入 body 流
如果等 c.MultipartForm() 完全解析后再读取文件，进度就无法实时上报——因为整个 body 已被读完或缓存。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
实操建议：
- 从
c.Request().Body拿原始流，用io.TeeReader(body, progressWriter)包一层，在数据流向multipart.Reader的同时写入进度统计 - boundary 值不能硬编码：应从
c.Request().Header.Get("Content-Type")中解析，而非假设它在c.Request().MultipartForm().Value["boundary"] - 避免用
time.Sleep()控制上报频率：它阻塞 goroutine，应改用time.AfterFunc()或 select + timer 非阻塞轮询
流式场景下 context.Done() 不可靠，需主动检测连接状态
客户端关浏览器、网络闪断、Nginx 默认 60s 超时，都可能导致 c.Request().Context().Done() 延迟触发甚至不触发，goroutine 就一直挂着。
实操建议：
- 在事件循环中用
select包裹：一个 case 监听c.Request().Context().Done()，另一个 case 每 5–10 秒尝试rw.(http.Flusher).Flush()并捕获write: broken pipe错误 - 一旦
Flush()报错，立刻 break 循环、关闭下游 channel、释放锁或取消子 context - 别依赖
http.CloseNotifier：Go 1.8+ 已弃用，且在多数反向代理后失效
真正难的不是写出能跑的流式逻辑，而是让每条连接在各种网络边界（CDN、WAF、移动基站）下都能稳定保活、及时释放。这些细节不写进 handler，只靠中间件或全局配置是兜不住的。
