安全处理用户上传图片需先读魔数校验格式并限制头部读取量，再用 DecodeConfig 检查尺寸阈值，统一转为 *image.RGBA 编码，JPEG 压缩设 Quality=75，流式写入避免内存堆积。
Go 语言本身不内置图片编解码，但标准库 image 和 image/jpeg、image/png 等包已足够支撑轻量级图片压缩服务；真正要注意的是内存控制、格式兼容性与并发安全——别直接用 image.Decode 处理未校验的上传图，容易 panic 或 OOM。
如何安全解码未知来源的图片
用户上传的文件可能伪造后缀、混入恶意数据，或尺寸极大。不能信任 filepath.Ext 判断格式，必须读取魔数（magic bytes）：
- 先用
io.LimitReader限制最多读 1024 字节，防止超大头部阻塞 - 调用
image.DecodeConfig获取宽高和格式，它只解析头部，不加载像素数据 - 检查
Config.Width * Config.Height是否超过阈值（如 2500×2500），超限直接拒绝 - 再根据
Config.ColorModel和格式选择对应解码器，避免image.Decode自动猜测失败
jpeg.Encode 压缩时控制质量与色彩空间
jpeg.Encode 的第三个参数是 *jpeg.Options，关键字段只有两个：Quality（1–100）和 PreserveJFIF（极少用）。但容易忽略的是：Go 默认输出 YCbCr 色彩空间，而浏览器对 RGB 更友好：
- 若源图是
*image.RGBA，直接 encode 不会转色，但若源是*image.YCbCr（常见于 JPEG 解码结果），encode 出来仍是 YCbCr，部分旧安卓 WebView 渲染异常 - 稳妥做法：统一转为
*image.RGBA，用draw.Draw(dst, dst.Bounds(), src, src.Bounds().Min, draw.Src) -
Quality=75是体积与观感平衡点；低于 60 会出现明显块效应，高于 90 体积增长快但人眼难辨
如何避免 goroutine 泄漏和内存堆积
HTTP handler 中启动 goroutine 处理图片，若没做上下文取消或超时，请求中断后 goroutine 仍运行，像素数据驻留内存：
立即学习“go语言免费学习笔记（深入）”；
- 所有 decode/encode 操作必须包裹在
ctx.Done()select 中，或用http.TimeoutHandler - 复用
bytes.Buffer（通过buffer.Reset()），别每次 new；大图建议用sync.Pool管理临时*image.RGBA图像缓冲区 - 对 PNG 做压缩时慎用
png.Encode，它不支持压缩级别；需用zlib.Writer手动包装 writer 并设置Level: zlib.BestSpeed防止 CPU 占满
真正棘手的不是“怎么压”，而是“压完怎么交还给 HTTP 连接”——别把压缩后图像全写进内存再 ResponseWriter.Write，用 io.Pipe 流式写入，一边 encode 一边 flush，否则 5MB 图片会瞬间申请 15MB 内存（RGBA 占 4 byte/px）。
