Go image/jpeg 怎样设置编码质量并保持 EXIF 边界

Go 的 image/jpeg 设置编码质量并不复杂：把质量值放进 jpeg.Options{Quality: n}，再传给 jpeg.Encode 即可，取值范围是 1 到 100，数值越高通常越接近原始像素、文件也更大。真正容易出问题的是 EXIF：标准库的 JPEG 编解码接口围绕 image.Image 和像素数据工作，重新编码时不会替应用自动搬运 EXIF 信息。

这篇文章复盘一个常见故障：缩略图的清晰度已经符合预期，但手机拍摄方向、拍摄时间等信息消失了。结论是把流程拆成两条线：像素数据交给 image/jpeg，EXIF 等元数据由应用显式读取、决定是否保留，再交给支持该格式的元数据处理组件。

先把故障现象拆成三件事

现场通常只有一句话：“转码后图片不对了。”这句话至少可能指向三种不同结果：

• 画面变糊或出现块状噪声：多半与 JPEG 有损编码质量、原图内容和重复转码有关。
• 文件变大或变小：质量值会影响体积，但尺寸、纹理、色彩和编码实现也会共同影响结果。
• 方向、时间、定位等信息消失：这是元数据链路的问题，不能靠把质量从 75 调到 95 修复。

因此，排查时先记录输入图像的宽高、目标质量和输出体积，再单独确认业务是否需要保留 EXIF。不要把“图片看起来正常”和“元数据仍在”当成同一条结论。

先读取尺寸，再决定是否完整解码

jpeg.DecodeConfig 只读取 JPEG 头部中的颜色模型和尺寸信息，不会像完整解码那样立刻分配整张像素图。批量处理外部图片时，可以先用它设置像素上限，再调用 jpeg.Decode。

package main

import (
    "bytes"
    "fmt"
    "image/jpeg"
)

func inspectJPEG(data []byte) (int, int, error) {
    // 先读头部，避免对尺寸异常的图片直接分配完整像素缓冲区。
    cfg, err := jpeg.DecodeConfig(bytes.NewReader(data))
    if err != nil {
        return 0, 0, fmt.Errorf("读取 JPEG 头部失败: %w", err)
    }

    // 这里的上限是业务示例，生产环境应按内存预算配置。
    const maxPixels int64 = 40 * 1000 * 1000
    if int64(cfg.Width)*int64(cfg.Height) > maxPixels {
        return 0, 0, fmt.Errorf("图片像素过大: %dx%d", cfg.Width, cfg.Height)
    }
    return cfg.Width, cfg.Height, nil
}

这一步只解决资源边界，不会改变编码质量，也不会读取 EXIF。它的价值是让后续转码的失败原因更容易区分：尺寸不接受，就不要把问题误判成编码器或元数据问题。

用 Options 设置质量并重新编码

image/jpeg 的 Options.Quality 取值范围是 1 到 100，默认值是 75。转码时建议把质量值作为明确的业务参数，而不是依赖空的 options；这样缩略图、预览图和归档图可以分别制定策略。

package main

import (
    "bytes"
    "fmt"
    "image/jpeg"
)

func transcodeJPEG(input []byte, quality int) ([]byte, error) {
    // 质量值越界时提前返回，避免把错误交给编码器后才发现。
    if quality  100 {
        return nil, fmt.Errorf("JPEG 质量必须在 1 到 100 之间: %d", quality)
    }

    // Decode 得到的是像素图；从这里开始，处理对象已经不是原始 JPEG 字节流。
    img, err := jpeg.Decode(bytes.NewReader(input))
    if err != nil {
        return nil, fmt.Errorf("解码 JPEG 失败: %w", err)
    }

    var output bytes.Buffer
    // Encode 只接收 image.Image 和编码选项，不会自动复制原文件的 EXIF 段。
    options := &jpeg.Options{Quality: quality}
    if err := jpeg.Encode(&output, img, options); err != nil {
        return nil, fmt.Errorf("编码 JPEG 失败: %w", err)
    }
    return output.Bytes(), nil
}

例如，质量 88 可以作为普通网页图片的起点，但它不是“清晰度百分比”，也不保证所有图片都得到同样的体积。品质选择应结合原图尺寸、纹理细节、上传限制和用户可接受的失真一起决定。

EXIF 为什么不会跟着像素图自动回来

JPEG 文件可以同时包含压缩后的图像数据和各种标记段。EXIF 属于标记段中的元数据，而 jpeg.Decode 返回的是实现了 image.Image 的像素对象；jpeg.Encode 也只根据这个像素对象和 Options 生成新的 JPEG。

所以，下面这个判断才是可靠的：

重新编码后的画面像素可以正确输出，不等于输入 JPEG 的 EXIF 会被保留。需要保留拍摄方向、时间或相机信息时，必须在像素转码之外建立独立的元数据处理步骤。

尤其要注意方向信息。某些查看器会根据 EXIF 方向显示“看起来正确”的照片；如果转码时丢掉方向段，又没有先把像素旋转到实际朝向，换一个不读取 EXIF 的环境后，图片就可能横过来。这个问题不是提高质量值能解决的。

线上修复时按这条边界处理

1. 先确定业务契约：如果输出只是缩略图，明确声明不承诺保留 EXIF；如果是照片归档或编辑链路，就把需保留的字段列出来。
2. 先处理方向再编码：需要视觉方向正确时，读取方向信息并把像素旋转到目标朝向，然后再编码；不要只把方向字段原样传下去。
3. 把质量作为可配置参数：用 1 到 100 的业务配置区分预览、正文和归档，不要把某个数值当成所有图片的通用答案。
4. 记录输入输出的可解释指标：保存宽高、质量值、输出大小和处理耗时；元数据是否保留则单独记录，不与文件大小混为一谈。
5. 限制外部图片的资源：在完整 Decode 前调用 DecodeConfig，设置宽高或像素总数上限，并对读取、解码、编码错误返回清晰原因。

质量值怎么选才不容易反复返工

如果同一图片需要多次处理，尽量从原始文件重新生成不同用途的版本，而不是拿已经压缩过的 JPEG 再次压缩。这样更容易把质量变化与元数据策略分别解释清楚。

常见问题

质量设置为 100 就一定无损吗？

不是。JPEG 仍然是有损格式，质量 100 只表示编码器使用更高质量参数，不能把已经丢失的信息恢复成无损原图。

只调用 jpeg.Decode 再 Encode，能保留原图方向吗？

不能据此保证。像素解码和 EXIF 方向是两个边界；需要方向正确时，应先处理方向语义或把旋转后的像素作为新的事实来源。

为什么同一个质量值输出大小仍然不同？

文件大小还受宽高、纹理、颜色分布和输入内容影响。质量值是编码参数，不是固定压缩比。

总结：用 jpeg.Options{Quality: n} 控制 JPEG 编码质量，用 DecodeConfig 先守住尺寸边界，把 EXIF 视为独立的元数据链路。只要像素、编码参数和元数据各自有明确责任，转码后的画质、体积与拍摄信息就不会再被一个模糊的“图片不对”绑在一起。