Go jpeg.DecodeConfig 怎么不解码像素读取尺寸

只想读取 JPEG 的宽高时，不需要先调用 jpeg.Decode。标准库提供的 jpeg.DecodeConfig 会返回 image.Config，其中包含 ColorModel、Width 和 Height，并且不会把整张图片解码成像素矩阵。

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

影响面：一次“只读尺寸”为什么拖慢上传接口

我排查图片上传链路时见过一种很隐蔽的浪费：接口只是想判断图片是否超过尺寸上限，代码却先调用 jpeg.Decode，拿到 image.Image 后再读 Bounds()。小图时差异不明显，遇到高分辨率 JPEG，服务会为像素数据付出额外的解码时间与内存成本。

触发条件并不复杂：业务只需要宽高，开发者却把“读取文件元信息”和“生成可操作像素”当成了同一个动作。修复点也很集中——把第一道检查改成 DecodeConfig，通过门禁后才执行完整解码。

根因：配置探测与像素解码是两条不同路径

官方文档给出的契约很明确：DecodeConfig 返回 JPEG 的颜色模型和尺寸，而不解码整张图。最小写法如下：

package main

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

func main() {
    // 打开文件后只读取 JPEG 配置，不展开整张图的像素。
    f, err := os.Open("photo.jpg")
    if err != nil {
        panic(err)
    }
    defer f.Close()

    cfg, err := jpeg.DecodeConfig(f)
    if err != nil {
        panic(err)
    }

    // Width 和 Height 就是图片的像素尺寸。
    fmt.Printf("%d x %d, model=%v\n", cfg.Width, cfg.Height, cfg.ColorModel)
}

这里没有构造完整的 image.Image。如果目标只是生成上传提示、选择缩略图策略或拒绝超大图片，到这一步通常已经足够。

时间线复盘：为什么同一个 Reader 不能直接再 Decode

最容易留下的第二个故障，是对同一个文件先调用 DecodeConfig(f)，紧接着调用 jpeg.Decode(f)。前一个函数为了读取配置已经消费了 Reader，后一个函数接到的就不是从 JPEG 起点开始的数据。

文件 Reader 可以用 Seek(0, io.SeekStart) 回到开头；HTTP 上传数据也可以先受限读取到字节切片，然后分别用两个 bytes.NewReader(data)。我更喜欢后一种写法，因为“探测”和“解码”各持有独立 Reader，边界一眼就能看明白。

修复动作：先设尺寸门禁，再决定是否解码

package main

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

const maxPixels int64 = 24_000_000

func decodeJPEG(data []byte) (image.Image, error) {
    // 第一个 Reader 只负责读取尺寸和颜色模型。
    cfg, err := jpeg.DecodeConfig(bytes.NewReader(data))
    if err != nil {
        return nil, err
    }

    // 先检查正数尺寸，再用 int64 计算像素总量，避免 int 乘法溢出。
    if cfg.Width  maxPixels {
        return nil, errors.New("JPEG 像素总量超过限制")
    }

    // 通过门禁后创建新的 Reader，从文件起点执行完整解码。
    return jpeg.Decode(bytes.NewReader(data))
}

maxPixels 应根据服务的内存预算、并发量和后续处理方式设定。它不是文件大小限制的替代品：压缩后的 JPEG 可能很小，但展开后的像素很多，因此字节上限和像素上限应该同时存在。

防复发：把检查顺序固定下来

• 先限制输入字节数：不要无上限地把上传流读入内存。
• 再调用 DecodeConfig：读取颜色模型、宽和高，并处理格式错误。
• 检查宽高与总像素：使用 int64 计算，避免平台相关的 int 溢出。
• 需要像素时才 Decode：使用新的或已回卷的 Reader。
• 不要把探测当校验器：DecodeConfig 能读取配置，不代表后续全部压缩数据一定完整可解码。

常见问题

问：DecodeConfig 会读取整个 JPEG 文件吗？
它的契约是不解码整张图片，但会从 Reader 读取足以得到配置的数据，因此调用后不能假设 Reader 仍停在开头。

问：只读取尺寸会不会分配完整像素内存？
不会像 jpeg.Decode 那样生成完整的 image.Image；返回值只是 image.Config。

问：后面还要生成缩略图怎么办？
先用配置做门禁，通过后重新打开文件、Seek 回起点，或基于同一份受限字节数据创建新 Reader，再调用 jpeg.Decode。