别用标准库 image.SubImage + draw.Draw 做批量裁剪，应优先选 github.com/disintegration/imaging；因 SubImage 返回原图视图而非副本，易致花屏、变黑或 panic，且 JPEG 编码需转 YCbCr，并发需限流防 OOM。
直接结论：别用标准库 image.SubImage + draw.Draw 做批量裁剪，内存和稳定性都扛不住；优先选 github.com/disintegration/imaging，配合 filepath.WalkDir 和带缓冲的 worker channel 控制并发。
为什么 image.SubImage 裁剪在批量场景下容易崩
它返回的是原图的“视图”，不是新图像。底层像素数组没复制，一旦原图被 GC 回收、或后续操作改写底层数组（比如同一张图反复 decode+resize），裁剪结果就可能花掉、变黑、甚至 panic。批量处理时这种问题往往延迟暴露，查起来极难定位。
- 必须显式深拷贝：先
sub := img.SubImage(r)，再dst := image.NewRGBA(sub.Bounds())，最后draw.Draw(dst, dst.Bounds(), sub, sub.Bounds().Min, draw.Src) - 更稳妥的做法是跳过 SubImage，直接用
imaging.Crop或imaging.Fill——它们内部做了边界检查和副本创建 - 如果坚持用标准库，务必确保
img生命周期覆盖整个裁剪+编码流程，且不被其他 goroutine 并发修改
jpeg.Encode 报 “cannot encode image.RGBA as JPEG” 怎么办
JPEG 不支持 Alpha 通道，而 Go 标准库解码后常返回 *image.NRGBA（PNG）或 *image.RGBA（某些 WebP），直接传给 jpeg.Encode 就会 panic。
- 安全转换路径：用
draw.Draw显式转成*image.YCbCr，这是 jpeg.Encode 唯一原生接受的类型 - 示例：
dst := image.NewYCbCr(img.Bounds(), image.YCbCrSubsampleRatio444); draw.Draw(dst, dst.Bounds(), img, img.Bounds().Min, draw.Src) - 用
imaging库可省这步：imaging.AdjustBrightness等操作会自动适配目标编码器；保存时传imaging.JPEGQuality(85)即可 - 别依赖
img.Convert(image.YCbCrColorModel)——它返回color.Color接口，不能直接喂给jpeg.Encode
并发批量处理时内存暴涨甚至 OOM
一张 4000×3000 的 JPEG 解码后约占用 36MB 内存（RGBA），10 张就是 360MB。不加控制地开 goroutine，很快打爆机器。
立即学习“go语言免费学习笔记（深入）”；
- 限制并发数：用带缓冲的
chan ImageTask+ 固定数量 worker（如 4–6 个），别用go process(path)每图一协程 - 及时释放：每张图处理完立刻设
img = nil，并确保没有闭包意外持有引用 - 提前过滤：用
image.DecodeConfig先读 header 判断尺寸，超限图直接跳过或降采样后再 full decode - 更省内存的替代：对大图优先用
imaging.Thumbnail，它内部做了流式缩放，避免全量加载
裁剪后图片旋转/颜色发灰的根因与绕过方式
原始 JPEG 带 EXIF Orientation 标记，Go 标准库 jpeg.Decode 默认忽略它，导致你裁剪的是“未旋转”的图，而浏览器按 EXIF 自动转正——看起来就像图被反向旋转了。颜色发灰则多因 YCbCr → RGB 转换越界（如 Cb/Cr 负值映射到 0）。
- 必须读 EXIF：用
github.com/rwcarlsen/goexif/exif解析Orientation字段 - 旋转要在裁剪前做：用
imaging.Rotate或手写逻辑，注意旋转后 bounds 会变，需重算裁剪区域 - 统一中间格式：所有处理步骤前，先转成
*image.RGBA（imaging.Clone可做到），避免色彩空间混用 - 快速验证：用
identify -verbose img.jpg查 Orientation 和色彩空间，别猜
最常被跳过的其实是 decode 后的 img == nil 检查，以及 SubImage 后的深拷贝——这两步省了，线上跑几天才突然出图异常，查起来特别费时间。
