直接用gin.context.saveuploadedfile会丢像素或变形，因其仅搬运文件、不解析修正exif方向（如iphone的orientation=6），导致后续image/jpeg.decode读取时旋转错位、坐标错乱；须在内存中解码→修正方向→裁剪→编码输出，禁用前端压缩以保exif完整。
为什么直接用 gin.Context.SaveUploadedFile 会丢像素或变形
移动端上传的图片常带 EXIF 方向信息（比如 iPhone 拍照后 Orientation=6），Gin 原生的 SaveUploadedFile 只做文件搬运，不解析/修正方向，后续用 image.Decode 直接读取就会旋转错位，裁剪框坐标全乱。这不是 Gin 的 bug，是 Go 标准库 image/jpeg 默认忽略 EXIF 的行为。
实操建议：
- 必须先用
github.com/rwcarlsen/goexif/exif或更轻量的github.com/h2non/bimg（基于 libvips）读取并修正方向 - 不要在保存前裁剪——原始图可能被压缩重编码，EXIF 丢失；应在内存中解码→旋转→裁剪→编码输出
- 若用
bimg，注意它默认启用自动旋转（Rotate: true），但需显式传入原始 buffer，不能依赖临时文件路径
裁剪参数怎么防绕过：x、y、width、height 必须校验边界
移动端前端传参不可信，常见攻击是构造负数 x 或超大 width 导致内存溢出或越界 panic。Gin 的 ShouldBindQuery 或 DefaultInt 不拦截非法值，得手动拦。
实操建议：
- 用
c.Query取字符串再转int，避免绑定时静默失败 - 校验逻辑必须包含：
x >= 0、y >= 0、width > 0、height > 0、x+width 、<code>y+height - 对超大图（如 >5000px 边长）加硬限制，防止 OOM：
if width*height > 25e6 { c.AbortWithStatusJSON(400, "max pixels exceeded") }
返回 JPEG 还是 WebP？移动端接口该选哪个
WebP 在 iOS 14+ 和 Android Chrome 全系支持，体积比 JPEG 小 25–35%，但 Go 原生 image/webp 库不维护，得用 github.com/kolesa-team/go-webp 或 bimg。JPEG 胜在稳定、无额外依赖。
实操建议：
- 若只支持现代移动端，优先 WebP：用
bimg的Convert方法，设置Quality: 85和Lossless: false - 若需兼容老 Android（jpeg.Encode(w, m, &jpeg.Options{Quality: 85, Progressive: true})
- 别用
Content-Type: image/*自动推断——明确写死c.Data(200, "image/webp", data)或"image/jpeg"
gin.Context.Writer 写响应体时为什么图片打不开
常见错误是调用 c.Header("Content-Type", "image/jpeg") 后，直接 c.Writer.Write(data)，但 Gin 的 Writer 有缓冲和状态管理，未调用 c.Status(200) 或 c.Writer.WriteHeader(200) 会导致 HTTP 状态码为 0，某些安卓 WebView 直接拒渲染。
实操建议：
- 必须显式设状态码：
c.Status(200)或c.Writer.WriteHeader(200)，且要在Write前 - 避免混用
c.Data()和c.Writer.Write()——Data内部已处理 Header 和 Status，Writer.Write是底层裸写，易冲突 - 若需流式传输大图，用
c.Stream+func() bool，但移动端裁剪图一般 c.Data 更稳
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
