image.decode常返回nil而不报错，因其仅对完全无法识别格式返回error；遇损坏头、exif过长或cmyk色彩空间时静默返回(nil, "jpeg", nil)。必须三值接收并检查img==nil，再用decodeconfig验证，批量时加日志跳过。
image.Decode 为什么经常返回 nil 而不报错
因为 image.Decode 在遇到损坏头、EXIF 过长、CMYK 色彩空间等“勉强能读但无法生成有效图像”的情况时，会静默返回 (nil, "jpeg", nil)。这不是 bug，是标准库设计行为——它只对完全无法识别的格式返回 error。
实操建议：
- 必须三值接收：
img, format, err := image.Decode(f)，且err == nil后仍要检查img == nil - 若
img == nil，先用image.DecodeConfig读取 header 判断是否真为图像（比如宽高 > 0），再决定跳过或报错 - 批量处理时加日志：
log.Printf("skip %s: decode returned nil image, format=%q", path, format)
jpeg.Encode 报错 cannot encode image.RGBA as JPEG 怎么办
JPEG 格式不支持 Alpha 通道，jpeg.Encode 只接受 *image.YCbCr 或能转为 YCbCr 的类型（如 *image.NRGBA 不行，*image.RGBA 也不行）。
安全做法是用 draw.Draw 显式转换：
dst := image.NewYCbCr(img.Bounds(), image.YCbCrSubsampleRatio444)
draw.Draw(dst, dst.Bounds(), img, img.Bounds().Min, draw.Src)
err := jpeg.Encode(outFile, dst, &jpeg.Options{Quality: 85})
常见错误场景：
- 直接传
*image.RGBA给jpeg.Encode→ panic - 用
nfnt/resize缩放后返回*image.NRGBA→ 必须再转一次才能存 JPEG - 偷懒用
imaging.AdjustColorBalance等第三方函数 → 引入依赖且未必解决颜色空间问题
缩放该用 resize.Resize 还是 imaging.Thumbnail
二者语义完全不同：resize.Resize(w, h, ...) 是强制拉伸/填充；imaging.Thumbnail(w, h, ...) 是等比缩放 + 居中裁切（类似 CSS object-fit: cover）。
选错会导致严重失真：
- 头像压缩后脸被压扁 → 错用了
resize.Resize固定宽高 - 商品图背景拉满、主体变形 → 同样是
resize.Resize强制适配 - 需要固定尺寸缩略图（如 200×200 头像）→ 用
imaging.Thumbnail - 只要限制最大宽度（如文章配图不超过 800px）→ 用
imaging.Resize(800, 0, img, filter)，高度传 0
并发批量压缩时内存暴涨甚至 OOM
直接为每张图起一个 goroutine（go process(file)）是典型翻车点：1000 张图 = 1000 个 goroutine，每个解码 JPEG 占几 MB 内存，16G 机器瞬间吃满。
稳住的关键是限流 + 流式处理：
- 用
filepath.WalkDir遍历路径，不一次性加载所有文件名到内存 - 建带缓冲的 job channel（如
chan job，buffer=100），主 goroutine 负责发任务 - 启动固定数量 worker（如 4 个），每个从 channel 拿 job，处理完再拿下一个
- worker 内部打开 → 解码 → 缩放 → 编码 → 关闭，全程不保留 img 引用
容易被忽略的一点：PNG 文件虽无质量参数，但 png.Encoder 支持 CompressionLevel，设为 flate.BestSpeed 可显著提速，尤其适合批量场景。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
