答案：应优先选用 github.com/disintegration/imaging 库。它封装 jpeg.Options 支持质量控制，内置 Lanczos 插值实现高质量等比缩放，避免盲目 resize 导致文件膨胀；需配合 image.Decode 获取原始尺寸判断是否缩放，并显式传 jpeg.Options{Quality: 60–75}，PNG 则需绕过默认编码、手动用 png.Encoder 控制压缩级别。
图片压缩该用哪个 Go 库？别直接上 resize
Go 原生 image 包不支持 JPEG 质量控制，golang.org/x/image 也只提供基础解码/编码，没压缩参数。真正能控质量、保比例、防失真的，目前最稳的是 github.com/disintegration/imaging —— 它封装了 jpeg.Encode 的 jpeg.Options，且自带智能缩放逻辑。
常见错误是直接用 imaging.Resize 然后无脑写入，结果文件变大（比如原图 800×600 已是小图，再 resize 到 1200×900 反而膨胀）；或者忽略 jpeg.Encode 的 Quality 参数，默认质量 75 太高，压不出效果。
- 判断是否需要缩放：先用
image.Decode拿到原始尺寸，对比目标宽高，只在任一维度超限时才 resize - 压缩必须显式传
&jpeg.Options{Quality: 70}，60–75 是实用区间，低于 60 易出块状伪影 - 别用
imaging.Fill或Crop做“等比裁切”，那是改构图，不是压缩；要的是imaging.Resize+imaging.Lanczos插值
Gin 中接收并压缩上传图片的最小可行路径
别在 c.FormFile 后立刻 Save 到磁盘再读取——多一次 I/O，还可能被恶意文件名攻击。正确做法是把 *multipart.FileHeader 的 Open() 返回的 io.ReadCloser 直接丢给解码器。
典型坑：Gin 的 c.SaveUploadedFile 不校验 MIME 类型，上传 .php 文件也能过；而 image.Decode 遇到非图会 panic，必须用 http.ErrNotSupported 捕获。
立即学习“go语言免费学习笔记（深入）”；
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 用
c.FormFile("file")获取上传头，检查header.Size < 10<<20（10MB 上限） -
src, _ := header.Open()，然后img, format, err := image.Decode(src)，format必须是"jpeg"或"png"（GIF 动图不建议压缩入库） - 目标尺寸按业务定，比如头像统一
width=200，调用imaging.Resize(img, 200, 0, imaging.Lanczos)，高度传 0 表示等比 - 写入响应或保存前，用
bytes.Buffer中转，避免临时文件：buf := &bytes.Buffer{}; jpeg.Encode(buf, resized, &jpeg.Options{Quality: 70})
如何让压缩后的 PNG 体积不爆炸？
PNG 本身无损，imaging 默认用 png.Encode，不压缩 palette，也不做滤波优化。一张 200×200 的 PNG 经 Resize 后可能比原图还大 3 倍——尤其当原图是摄影类 JPEG 转 PNG 时。
解决办法不是换库，而是绕过 imaging 的 PNG 编码，手动用 png.Encoder 控制 png.Encoder.CompressionLevel，并启用 png.FilterNone 减少冗余。
- 对 PNG 输入，先转为
*image.NRGBA（避免 alpha 混合问题）：dst := imaging.Clone(img); dst = imaging.ConvertColorSpace(dst, color.NRGBAModel) - 不用
imaging.Save，改用：enc := &png.Encoder{CompressionLevel: png.BestCompression}; enc.Encode(w, dst, nil) - 如果业务允许，强制转 JPEG：PNG 仅用于图标/透明图，普通图片一律存 JPEG，省空间也省解码开销
并发压缩时内存暴涨怎么办？
imaging.Resize 内部会分配新图像内存，一张 4000×3000 的 JPEG 解码后占约 48MB（4000×3000×4 字节），10 个并发就吃掉近 500MB。Gin 默认不设路由级并发限制，容易 OOM。
根本解法不是加机器，而是用 runtime/debug.FreeOSMemory() 强制 GC——但治标不治本；更可靠的是复用 bytes.Buffer 和限制 goroutine 数量。
- 用
semaphore控制并发数，比如var sem = make(chan struct{}, 3)，每个请求sem <- struct{}{}，处理完<-sem - 避免在 handler 里新建大 buffer，改用
sync.Pool复用：var bufPool = sync.Pool{New: func() interface{} { return new(bytes.Buffer) }} - 对大图（>2MP），先用
jpeg.DecodeConfig拿宽高，超阈值直接拒收，别等到Decode才发现内存扛不住
压缩不是越狠越好，70 质量 + 等比缩放到目标尺寸，基本覆盖 90% 场景；真要极限压，得上 mozjpeg 或 cjpeg，Go 里跑 shell 不如直接用独立服务，别硬塞进 Gin handler。
