c.saveuploadedfile会卡住大图上传，因为它依赖net/http的multipart解析机制，必须先将整个文件落地到内存或临时磁盘才能调用；无法流式处理，导致超5mb图片阻塞、无法预处理（如读尺寸/裁剪），且无超时与并发控制，易引发goroutine泄露和oom。
为什么直接用 gin.Context.SaveUploadedFile 会卡住大图上传
超过 5MB 的图片在默认 Gin 配置下，c.SaveUploadedFile 会阻塞等待完整写入磁盘，期间无法做任何预处理（比如读取尺寸、裁剪），更没法流式解码。这不是 Gin 的 bug，而是它底层依赖 net/http 的 multipart 解析机制——必须先把整个文件落地，才能调用 SaveUploadedFile。
真正要做的，是绕过文件落地，从 *multipart.FileHeader 的 Open() 方法拿到 io.ReadCloser，直接喂给图像解码器。
- 必须提前调用
c.Request.ParseMultipartForm(32 （例如 32MB），否则解析时会 panic：<code>http: multipart: Part.Read: multipart: message too large -
fileHeader.Open()返回的 reader 只能读一次，且不支持 seek，所以缩略图生成逻辑必须“单趟完成” - 别在 handler 里用
image.Decode直接解大图——JPEG/PNG 的 header 解析很快，但全量解码会吃光内存；优先用jpeg.DecodeConfig或png.DecodeConfig拿宽高
怎么用 golang.org/x/image/draw 安全缩放而不爆内存
Gin handler 里不能无脑调 draw.Bilinear 或 draw.CatmullRom，它们会把原图全量解码进内存。10MB 的 8000×6000 JPEG 全解码后可能占 200MB+ RAM，瞬间 OOM。
正确做法是：先用 image.DecodeConfig 获取原始尺寸 → 计算目标尺寸 → 用 jpeg.Decode（或 png.Decode）配合 jpeg.DecodeOptions{ScaleDenominator: N} 做硬件友好的降采样（仅对 JPEG 有效），再用 draw.ApproxBiLinear 做二次微调。
- JPEG 场景下，设
opts := jpeg.DecodeOptions{ScaleDenominator: 4}可让解码器跳过 3/4 像素，内存占用下降约 75% - PNG 不支持
ScaleDenominator，只能靠draw.Thumbnail（注意：它内部会全量解码，慎用于 >2MB 文件） - 缩略图宽度/高度超过 2000 像素时，建议强制加
runtime.GC()，避免 GC 延迟导致并发请求堆积
如何让接口返回缩略图而不保存到磁盘
用户要的是“HTTP 返回图”，不是“存到某个目录”。Gin 默认的 c.Data 或 c.DataFromReader 就够用，关键是要设置正确的 Content-Type 和禁止缓存（除非你真想 CDN 缓存）。
- 用
mime.TypeByExtension(filepath.Ext(originalName))推断类型，但注意上传字段可能没扩展名，fallback 到http.DetectContentType(buf[:min(512, len(buf))]) - 务必设
c.Header("Content-Disposition", "inline; filename=\"thumb.jpg\"")，否则浏览器可能下载而不是预览 - 别漏掉
c.Header("Cache-Control", "no-store")—— 否则 Nginx 或浏览器缓存了损坏的缩略图，后续请求永远返回错图 - 如果用
c.DataFromReader，reader 必须是io.Reader（如bytes.NewReader(buf)），不能传 *bytes.Buffer —— 后者实现了io.Writer但不是io.Reader
并发缩略图请求下怎么避免 goroutine 泄露
看似只是个图片处理接口，但用户批量上传或前端轮询时，容易触发大量并发请求。Gin 默认不限制并发数，而图像解码函数（尤其是 jpeg.Decode）底层会调用 CGO，goroutine 一旦卡在 C 调用里，就无法被调度器抢占。
- 必须用带超时的 context：
ctx, cancel := context.WithTimeout(c.Request.Context(), 10*time.Second)，并在 decode 前检查ctx.Err() - 禁止在 handler 内启动无管控的 goroutine（比如
go resize(...)），所有耗时操作必须在当前 goroutine 完成，或交给带 buffer 的 worker pool - 用
pprof抓/debug/pprof/goroutine?debug=2，重点看状态为syscall或CGO的 goroutine 数量是否持续上涨 - 上线前压测时，观察
runtime.NumGoroutine()是否随 QPS 线性增长 —— 如果是，说明有 goroutine 没回收
缩略图的核心矛盾从来不是“怎么画小图”，而是“怎么不让大图拖垮服务”。每一步都要预设失败路径：IO 超时、内存不足、格式不支持、并发打满。留出退路比写出漂亮代码更重要。
