imagejpeg编码图片

Go 编码 JPEG 使用 image/jpeg 的 jpeg.Encode，传入写入目标、image.Image 和编码选项即可。质量参数范围是1到100，传 nil 选项时使用默认质量75。真正接入上传服务时，我会先决定透明区域的底色、编码结果交付方式和失败处理，再选质量值。

官方地址：https://pkg.go.dev/image/jpeg

假设要为上传照片生成浏览用的预览文件，我倾向于先做一个返回字节切片的小函数，让 HTTP 层和文件保存层共用。下面是这种设计取舍的示例，不是线上压测或亲历故障记录。讨论的输入已经是解码后的图片，不包含上传解析和缩略图缩放。

先判断这张图是否适合 JPEG

照片预览与透明图标的需求并不相同。前者可以在体积和细节之间取舍，后者可能必须保留透明区域。JPEG 不承担透明通道的保留需求；若决定输出 JPEG，应明确把透明像素合成到什么背景，避免把背景选择留给隐含转换行为。

我会把“输出格式”和“输出尺寸”分开配置。降低质量不会自动缩小图片宽高；编码函数也不负责把大图缩成缩略图。这样排查文件过大时，可以分别观察像素数量和编码质量，不必一上来就把质量压得很低。

把编码入口保持为一个小函数

官方接口是 Encode(w io.Writer, m image.Image, o *Options) error。这让我更愿意把它看成“向指定目标写 JPEG 数据”的函数，而不是只能保存 jpg 文件的工具。文件、缓冲区以及响应写入对象都可以作为目标，具体资源生命周期仍由调用方安排。

下面采用白色背景和显式质量检查。边界检查是这个业务包装函数的约定，不依赖编码器如何处置越界参数。

package preview

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

// EncodeWhiteJPEG 接受已解码且尺寸受控的图片，返回白底 JPEG。
func EncodeWhiteJPEG(src image.Image, quality int) ([]byte, error) {
    if src == nil {
        return nil, fmt.Errorf("源图片不能为空")
    }
    if quality  100 {
        return nil, fmt.Errorf("质量必须在 1 到 100 之间")
    }
    bounds := src.Bounds()
    if bounds.Empty() {
        return nil, fmt.Errorf("源图片尺寸为空")
    }

    // 背景先填为不透明白色；再将源图按透明度覆盖上去。
    dst := image.NewRGBA(image.Rect(0, 0, bounds.Dx(), bounds.Dy()))
    draw.Draw(dst, dst.Bounds(), image.NewUniform(color.White), image.Point{}, draw.Src)
    // 源图不一定从 (0,0) 开始，使用 bounds.Min 对齐。
    draw.Draw(dst, dst.Bounds(), src, bounds.Min, draw.Over)

    var buf bytes.Buffer
    if err := jpeg.Encode(&buf, dst, &jpeg.Options{Quality: quality}); err != nil {
        return nil, fmt.Errorf("编码 JPEG: %w", err)
    }
    // 成功后才把完整编码结果交给调用方，调用方负责保存或响应。
    return buf.Bytes(), nil
}

这段代码作为 preview 包中的函数使用。调用方传入受控的 image.Image 与质量值，例如85；成功得到的是 JPEG 编码字节，而不是原始像素。85只是便于开始比较的示例值，不代表所有照片的最佳参数。

这里有一个容易忽略的小细节：源图 Bounds 的最小坐标不保证是零。用 bounds.Min 对齐来源，能让从其他图片裁出的子图也按其实际区域合成。目标图片则统一从零坐标开始，后面的编码与原图坐标无关。

为什么我先返回字节，而不是直接写响应

小尺寸预览的场景里，我更看重失败时还没把半份响应交给客户端。先编码到 bytes.Buffer，只有成功后才让外层保存或返回，错误路径比较容易解释。这种写法的代价也很明确：缓冲区占内存，白底合成还会新增一份像素存储。

如果要处理大图或高并发请求，我不会把这个示例直接无限放大。可以改成写临时文件，完成并关闭后再交付；或者按业务协议流式写入，但接受“写到一半可能失败”的后果。并发数量、像素上限和缓存策略要一起考虑。

保存与响应时，把失败边界写清楚

如果外层使用文件目标，需要处理创建、编码写入和关闭错误。先创建正式目标再编码，会有残留不完整文件的可能；可根据存储需求选择临时位置与最终交付步骤。这里不把任何文件改名方式承诺为跨文件系统通用事务。

如果外层返回 HTTP，先完成上述字节编码，再设置与内容一致的 image/jpeg 类型。实际写响应也可能失败；不要已经写出响应后，又追加一段 JSON 错误文本，那会破坏图片数据。文件名后缀也应与编码格式一致，不能只把原 PNG 名字改成 jpg 就当作完成转换。

对上传入口，我会在进入该函数前限制文件读取量与解码后的像素规模。小文件不一定对应小尺寸图片，内存估算不能只看上传字节数。本函数默认输入可信且尺寸受控，也不负责 EXIF 方向、元数据保留或颜色管理等完整转码任务。

适合谁，以及常见问题

这个小函数适合已经拿到 image.Image、希望统一输出白底 JPEG 的预览或导出逻辑。必须保留透明图标、要求完整元数据，或需要大规模流式处理的任务，应在它之外补齐相应能力。

Quality 设为100就无损了吗？不能把质量参数当作无损承诺。对需要像素精确保留的内容，应另选适合的编码方式。

为什么转换后体积没有预想的小？先区分图片尺寸、画面细节和质量参数。示例没有缩放功能，也不保证任意输入都会比原文件更小。

jpeg.Encode 会关闭目标文件吗？它接收的是 io.Writer，关闭文件等生命周期由持有资源的调用方处理。

这里会覆盖原图片吗？函数创建新的白底目标和缓冲区，不修改源图；最终是否覆盖某个文件，由外层保存逻辑决定。

参考：Go JPEG 编码文档、Go 图片合成与坐标说明。