gin 不自动压缩图片，需手动处理解码、缩放、编码；常见问题包括未检查 image.decode 返回值、jpeg 解码内存暴涨、临时文件未清理；上传后须先保存至唯一临时路径再压缩，且需显式调用 parsemultipartform 并设置 maxmemory。
别指望 Gin 自己压缩图片——它只管 HTTP 转发，解码、缩放、编码全得你手写；真正卡住的不是算法，而是 image.Decode 返回 nil 没检查、JPEG 解码后内存暴涨没限并发、临时文件没清理就 panic 导致磁盘悄悄占满。
上传后立刻保存到唯一临时路径再压缩
HTTP handler 里拿到 r.FormFile 后不能直接传给压缩逻辑，因为底层 reader 还没把完整数据写入磁盘。必须先落盘，且路径要唯一、可清理。
-
ParseMultipartForm必须显式调用，maxMemory建议设为32 （32MB），否则 <code>r.FormFile可能返回nil或 panic - 用
os.CreateTemp("", "upload-*.bin")生成临时路径，避免多请求冲突 - 保存后务必检查
file.Close()的 error —— 否则 fd 没释放，后续os.Remove会失败 - 压缩失败时，必须在
err != nil分支里立即os.Remove(tmpPath)，defer 不够用
按格式分发编码器，别混用 jpeg.Encode 和 png.Encode
不同格式的压缩逻辑差异极大，硬套同一套参数会 panic 或输出异常（比如 PNG 体积翻倍、WebP 静默失败）。
- JPEG：用
jpeg.Encode(dst, img, &jpeg.Options{Quality: q})，推荐质量区间75–85；低于60明显色块，高于90体积增长快但人眼难辨 - PNG：标准库默认不压缩，必须用
png.Encoder{CompressionLevel: png.BestCompression}，否则体积可能翻倍 - WebP：需手动导入解码器
_ "golang.org/x/image/webp"，编码用webp.Encode(dst, img, &webp.Options{Lossy: true, Quality: 80}) - 别信文件扩展名，用
image.DecodeConfig返回的Format字符串（如"jpeg"）做分发依据
并发压缩必须用 worker pool 控制 goroutine 数量
直接对每个上传起 go process(file) 是最常见 OOM 原因：100 张高清图 ≈ 100 个 goroutine，每张 JPEG 解码占 5–20MB 内存，16GB 机器秒崩。
- worker 数量建议固定为
4–8，用带缓冲的chan ImageTask（缓冲大小建议100）防生产者阻塞 - 每个 worker 必须包一层
defer func(){recover()}()，否则imaging.Resize遇损坏图 panic 会导致整个 goroutine 消失 - 任务入队前先调
image.DecodeConfig快速校验格式和尺寸，跳过损坏或超小图（如 100×100），避免无效解码 - 别用
filepath.Walk一次性加载所有路径到内存，改用filepath.WalkDir流式发任务
压缩不是独立步骤，它依赖保存动作的完整性
最容易被忽略的是：压缩失败 ≠ 文件没写完。临时文件残留、fd 锁死、磁盘占满，往往源于 Close() 错误没检查、panic 发生在中间某步、或 os.Remove 被 defer 推迟到函数退出后才执行。
-
file.Close()的 error 必须显式判断，否则底层 fd 可能未释放，导致后续os.Remove报text file busy - 不要依赖
filepath.Join(os.TempDir(), ...)存原图——os.TempDir()可能被系统自动清理，建议用固定路径如/var/tmp/uploads并配 logrotate - 如果用了
multipart.File.Seek(0, io.SeekStart)多次读取，每次读完都得回位，否则第二次image.Decode读空 - 真正压不住的从来不是尺寸，而是质量参数选错、Alpha 通道没保留、EXIF 旋转没处理——这些错误不会报 panic，但产出图是错的
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
