Gin大文件下载必须用c.DataFromReader流式传输，而非c.File；因后者全量加载文件至内存导致OOM、无流控、不支持断点续传，而前者内存恒定、可控且是生产环境默认做法。
Gin 本身足够快，但默认配置在真实高并发场景下会迅速暴露瓶颈——比如 100MB 文件下载时内存峰值冲到 8GB、1GB 文件直接触发 OOM，不是框架不行，是没关掉“自动加载全量内容”这个默认开关。
为什么 wrk 测出的 QPS 和线上表现差很远
基准测试（如 wrk -t12 -c400 -d30s）只压测了空路由或简单 JSON 返回，掩盖了三个关键现实因素：
- 真实请求带 body 解析（尤其是 multipart/form-data 或大 JSON），
c.ShouldBindJSON()默认把整个请求体读进内存再解析 - 中间件链中未做 early-return，比如鉴权失败仍继续执行后续中间件和 handler
- 日志中间件未异步或限流，高并发下
log.Printf成为锁竞争热点
实操建议：用 pprof 抓取生产流量下的 CPU 和 heap profile，重点关注 io.ReadAll、encoding/json.Unmarshal 和 fmt.Sprintf 的调用栈深度和耗时占比。
文件下载卡顿、内存爆炸的根因与修复
现象是响应慢、内存飙升，本质是 Gin 默认用 c.Data 或 c.File 时，底层调用了 io.ReadAll 把整个文件读进内存再写出去。100MB 文件 = 100MB 内存/请求 × 并发数。
- 改用流式传输：
c.DataFromReader+os.Open+http.ServeContent组合，避免全量加载 - 显式设置
Content-Disposition头，防止浏览器尝试解析二进制内容 - 对大文件启用
sendfile（需 Linux +net/http底层支持），Gin 本身不拦截该路径，但要确保c.Writer未被中间件提前写入
示例关键片段：
f, _ := os.Open(filepath) defer f.Close() stat, _ := f.Stat() c.DataFromReader(200, stat.Size(), "application/octet-stream", f, nil)
Goroutine 泄漏与 Worker Pool 控制
高频短任务（如日志上报、消息推送）若直接起 go func() { ... }()，在突发流量下会瞬间创建数万 Goroutine，调度器压力陡增，且容易忘记 recover 导致 panic 波及主线程。
- 用固定大小的 Worker Pool 管理异步任务，池大小建议设为
runtime.NumCPU() * 2起步 - Pool 中每个 worker 从 channel 消费任务，channel 容量设为 1024 以内，避免缓冲区堆积
- 禁止在中间件里直接启动 goroutine；所有异步逻辑统一走 pool，且任务函数必须包含
defer recover()
注意：gin.Context 不能跨 goroutine 传递——它绑定到当前 HTTP 请求生命周期，子 goroutine 中调用 c.Abort 或 c.JSON 会 panic。
优雅停机缺失导致连接中断
Gin 默认无优雅停机，kill -SIGTERM 后新连接拒绝，但已有长连接（如 WebSocket、流式接口）会被立即切断，客户端收到 connection reset。
- 必须手动集成
http.Server.Shutdown，监听 OS 信号 - 设置合理的
ShutdownTimeout（建议 10–30 秒），太短丢请求，太长拖慢发布 - 在 Shutdown 前调用
srv.Close()停止接受新连接，再等活跃连接自然结束
最容易被忽略的是：若用了自定义 http.Transport 或反向代理中间件，需同步关闭其 idle connections，否则 Shutdown 可能阻塞超时。
