直接用gin.context.saveuploadedfile会丢质量，因其仅原样保存文件，未解码重编码；无损压缩需用image.decode后对png设png.bestcompression、jpeg设quality=100重编码。
为什么直接用 gin.Context.SaveUploadedFile 会丢质量？
因为 Gin 默认只是把上传的原始文件原封不动写到磁盘，不经过任何处理。所谓“无损压缩”必须在保存前对图像数据做解码-重编码操作，而 SaveUploadedFile 完全跳过这一步。你拿到的是用户上传的原始 JPEG/PNG，可能带冗余元数据、非最优 Huffman 表、未清理的 EXIF，甚至本身就是有损格式（比如高倍率 JPEG）。真正的无损压缩，其实是“无损重编码”——保留所有像素值，但减小体积。
怎么用 golang.org/x/image 对 PNG/JPEG 做无损重编码？
Go 标准库的 image/jpeg 和 image/png 包支持配置编码参数，但默认行为不是无损的。关键点在于：PNG 本身是无损格式，重编码时只要不用 png.Encoder 的 CompressionLevel 降级（保持默认或设为 png.BestCompression），就能做到无损；JPEG 则必须用 jpeg.Encode 且 Quality 设为 100 —— 注意，Quality=100 不等于“原始”，而是 Go JPEG 编码器能达到的最高保真度，像素值完全一致，但文件大小可能略增或略减，取决于原始编码效率。
实操建议：
- 先用
image.Decode解码上传的*multipart.FileHeader，识别格式（jpeg/png/gif） - PNG 场景：用
png.Encoder+png.Encoder.CompressionLevel = png.BestCompression - JPEG 场景：用
jpeg.Encoder+jpeg.Options{Quality: 100} - 避免用
io.Copy直接转发原始 body，否则绕过解码重编码，等于没压缩
gin.Context.Request.MultipartForm 提前读取导致后续解析失败？
Gin 的 c.FormFile 内部会调用 ParseMultipartForm，但一旦你手动调用过 c.Request.ParseMultipartForm 或提前读了 c.Request.Body，再调用 c.FormFile 就会返回 nil 或报错 http: multipart: NextPart: EOF。这是 Go HTTP 标准库的底层限制：multipart body 只能被读一次。
正确做法：
- 只调用一次
c.FormFile("image")获取*multipart.FileHeader - 用
fileHeader.Open()得到multipart.File（本质是io.ReadCloser），然后传给解码逻辑 - 不要在解码前做
io.ReadAll(c.Request.Body)或c.Request.MultipartForm手动解析 - 如果需同时处理多个字段，用
c.Request.FormValue("xxx")读文本字段，c.FormFile读文件字段，二者互不干扰
无损压缩后文件反而变大？常见原因和应对
这不是 bug，而是格式特性决定的。比如：原始 JPEG 含大量 EXIF（相机型号、GPS、缩略图），重编码为 Quality=100 时 Go 默认不保留 EXIF；原始 PNG 使用了自定义调色板或隔行扫描，而标准 png.Encoder 生成的是更通用但稍大的格式。结果就是“无损”但“不一定更小”。
可选对策：
- 对 JPEG：用
github.com/rwcarlsen/goexif/exif提前读 EXIF，再用jpeg.Encode的Options中的ExtraData字段写回去（注意：Go 标准库不支持，需第三方包如github.com/disintegration/imaging） - 对 PNG：改用
github.com/knq/sysutil/png或直接调用optipng二进制（通过exec.Command），它能在无损前提下做更多优化（如调色板排序、过滤器选择） - 上线前务必用真实样本压测：同一张图上传 10 次，统计大小变化范围，别只信单次结果
真正难的不是写通流程，而是判断哪些图该走 PNG 重编码、哪些该转 JPEG、哪些干脆不碰——这得看业务场景里用户上传的原始格式分布和 CDN 对格式的支持程度。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
