Go image/png.DecodeConfig 怎么先读尺寸再解码：Reader 消费位置与图片头边界

做图片上传接口时，常见需求是先读出 PNG 的宽高，再决定是否继续解码。问题在于，png.DecodeConfig 不是“只看一眼就把 Reader 原样放回去”：它会消费输入。对可回退的 bytes.Reader，调用 Seek(0, io.SeekStart) 后再交给 png.Decode；对网络流或管道，则应把数据缓存下来，不能假定还能从头读。

DecodeConfig 适合先做尺寸检查，但它会推进 Reader；只有回到 PNG 起点，后续完整 Decode 才可靠。

DecodeConfig 读取尺寸但会消费 Reader

image/png.DecodeConfig(r io.Reader) 读取 PNG 的配置，返回 image.Config。最有用的字段是 Width、Height 和 ColorModel。上传接口可以先判断面积上限，例如宽高任一超过业务限制就拒绝，不必先把整张图片解成像素。

但参数类型是 io.Reader，而不是 io.ReadSeeker。函数只承诺读配置，不承诺调用结束后 Reader 仍位于原位置。这个差异正是“尺寸检查通过，后面 Decode 却报错”的来源。

同一份 PNG 的 Reader 位置会怎样变化

下面的示例在内存中用 Go 标准库编码一张 2×1 PNG，然后使用同一个 bytes.Reader 依次调用配置读取和完整解码。运行命令是：

go run article-drafts/1788064060-45-go-png-decodeconfig/example.go

第一次输出显示 reader_pos=33/73。这说明配置已经从输入头部读走了一部分字节；紧接着调用 png.Decode(r) 会从中间位置开始，得到 png.FormatError: png: invalid format: not a PNG file。

r := bytes.NewReader(data)
config, err := png.DecodeConfig(r)
if err != nil {
    return err
}
pos, _ := r.Seek(0, io.SeekCurrent)
fmt.Println(config.Width, config.Height, pos)

// 这里不能直接 Decode(r)，因为 r 已经不在 PNG 起点。
if _, err := png.Decode(r); err != nil {
    fmt.Println(err)
}

回退 Reader 后再执行 Decode

bytes.Reader 实现了 io.ReadSeeker，所以尺寸检查通过后，可以把位置恢复到 io.SeekStart。恢复动作应紧挨着完整解码，避免中间又有别的读取逻辑改变位置。

if _, err := r.Seek(0, io.SeekStart); err != nil {
    return err
}
img, err := png.Decode(r)
if err != nil {
    return err
}
fmt.Println(img.Bounds())

同一实验回退后输出 bounds=(0,0)-(2,1)，终端记录 reader_pos=73/73。这里的边界正好与前面生成的 2×1 图片一致，说明 Decode 从文件头重新开始并读完了输入。

没有 Seek 时，先把输入保存下来

HTTP 请求体、管道或压缩层通常只提供 io.Reader。这时不要强行断言它支持 Seek。一个稳妥做法是先用 io.ReadAll 读取原始字节，做完大小上限检查后，分别用两个 bytes.NewReader(data) 创建配置检查和完整解码的读取视图。

data, err := io.ReadAll(body)
if err != nil {
    return err
}
if len(data) > 10 4096 || config.Height > 4096 {
    return fmt.Errorf("image dimensions exceed limit")
}
img, err := png.Decode(bytes.NewReader(data))

这种写法多占一份字节存储，但把“配置读取”和“完整解码”彻底隔离，适合需要重复读取、记录原始文件或执行多项校验的接口。大文件场景则应改用临时文件或带上限的读取器，避免把不受控的请求体全部放进内存。

相关问答：几个容易混淆的边界

DecodeConfig 成功是否代表图片一定能完整解码？

不代表。它主要读取配置阶段所需的数据；文件尾部损坏、校验失败或后续像素数据异常，仍可能在 png.Decode 时暴露。

为什么不能只判断 Reader 是否实现 Seek？

实现 io.Seeker 只说明可以尝试定位，不代表任何来源都适合频繁回退。网络流本身通常不可 Seek，包装器的 Seek 也可能有额外成本。把输入缓存为有明确上限的字节或临时文件，边界更清楚。

尺寸检查应该放在完整解码前吗？

应该。先检查宽高和总字节数，可以尽早拒绝超限输入；不过不要把配置检查当成完整文件安全校验，最终仍需处理 Decode 的错误。

把判断写进代码和测试

测试至少覆盖三件事：配置宽高与预期相同；未回退的 Reader 会失败；回退或重新创建 Reader 后能够得到正确边界。这样以后替换输入来源时，Reader 位置的隐含假设会立刻暴露。

记住这一条就够用：DecodeConfig 是预检查，不是无副作用的探测器。可 Seek 的输入回到起点，不可 Seek 的输入先保存，再把独立 Reader 交给后续阶段。