image/png png.DecodeConfig 如何先读尺寸再决定分配

处理用户上传的 PNG 时，直接调用 png.Decode 会立刻进入完整图像解码。更稳妥的分工是：先用 png.DecodeConfig 读取颜色模型、宽度和高度，尺寸通过后再重新提供一个可读的 io.Reader 给 png.Decode。这样可以把“是否值得继续分配和解码”的判断放在完整图像对象出现之前。

官方文档：https://pkg.go.dev/image/png

核心要点：DecodeConfig 返回的是 image.Config，不是 image.Image；它会消耗 Reader 的前部数据，因此后续完整解码必须重新打开文件、重新创建 Reader，或把输入先保存为可重复读取的数据。

先把问题拆成两个阶段

这类故障通常表现为“尺寸异常的图片一进来，内存分配和解码一起发生”。根因不是两个函数名字相近，而是它们的返回对象不同：

• png.DecodeConfig(r) 返回 image.Config，包含 ColorModel、Width 和 Height，用于做输入边界判断。
• png.Decode(r) 返回 image.Image，需要继续读取并解析图像数据，适合尺寸通过后的实际处理。

因此，DecodeConfig 适合放在入口处，负责“看清楚再决定”；Decode 放在边界判断之后，负责“确实需要时才得到完整图像”。它不是转码函数，也不会替你完成业务层的尺寸上限策略。

用 DecodeConfig 读取尺寸再做边界判断

如果输入来自文件，最容易理解的写法是分两次打开：第一次只读配置，第二次在配置通过后才做完整解码。下面的示例限制宽高和像素总量，避免把尺寸判断与 PNG 转码混在一起。

package main

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

const (
    maxWidth  = 4096
    maxHeight = 4096
    maxPixels = int64(16000000)
)

func decodePNG(path string) (image.Image, error) {
    // 第一次打开只读取 PNG 配置，不创建完整 image.Image。
    configFile, err := os.Open(path)
    if err != nil {
        return nil, fmt.Errorf("打开配置输入: %w", err)
    }
    config, err := png.DecodeConfig(configFile)
    closeErr := configFile.Close()
    if err != nil {
        return nil, fmt.Errorf("读取 PNG 配置: %w", err)
    }
    if closeErr != nil {
        return nil, fmt.Errorf("关闭配置输入: %w", closeErr)
    }

    // 先检查单边和像素总量，再允许完整解码。
    pixels := int64(config.Width) * int64(config.Height)
    if config.Width  maxWidth || config.Height > maxHeight ||
        pixels > maxPixels {
        return nil, fmt.Errorf("PNG 尺寸超出限制: %dx%d", config.Width, config.Height)
    }

    // DecodeConfig 已经消耗了 Reader，所以这里必须重新打开文件。
    imageFile, err := os.Open(path)
    if err != nil {
        return nil, fmt.Errorf("打开完整输入: %w", err)
    }
    decoded, err := png.Decode(imageFile)
    closeErr = imageFile.Close()
    if err != nil {
        return nil, fmt.Errorf("完整解码 PNG: %w", err)
    }
    if closeErr != nil {
        return nil, fmt.Errorf("关闭完整输入: %w", closeErr)
    }
    return decoded, nil
}

这里的检查值只是示例策略，不是 image/png 规定的固定上限。实际项目应依据业务图片用途、进程内存和并发量设定。把宽高转换为 int64 后再相乘，也能避免在较窄整数类型中计算像素总量时出现溢出风险。

为什么不能直接复用刚才的 Reader

DecodeConfig 不是“旁路查看”。它会从 Reader 读取 PNG 头和必要的配置块，Reader 的当前位置已经前进；接着把同一个 Reader 传给 png.Decode，得到的可能是不完整输入或解析错误。

内存输入可以用 bytes.NewReader 创建两个独立游标；文件输入则可重新 os.Open。如果输入本来就是网络流，想做两阶段读取就要先把数据落到受控的内存或临时文件中，同时设置总字节数限制。不要为了“复用 Reader”而假设它支持回退。

import "bytes"

func decodeBytes(data []byte) (image.Image, error) {
    // 两个 Reader 共享字节数据，但各自维护独立读取位置。
    config, err := png.DecodeConfig(bytes.NewReader(data))
    if err != nil {
        return nil, fmt.Errorf("读取配置: %w", err)
    }
    if config.Width > maxWidth || config.Height > maxHeight {
        return nil, fmt.Errorf("尺寸过大: %dx%d", config.Width, config.Height)
    }

    // 通过边界后再从头解码，避免把已前进的 Reader 继续交给 Decode。
    decoded, err := png.Decode(bytes.NewReader(data))
    if err != nil {
        return nil, fmt.Errorf("读取图像: %w", err)
    }
    return decoded, nil
}

示例中的 data 仍然需要由调用方控制大小；“先看 PNG 尺寸”不能替代对上传字节流本身的限制。配置读取成功，也不代表后续完整解码一定成功，损坏的 IDAT 数据、校验错误等仍应在 Decode 返回处处理。

最后保留这张速查表

可以把这条规则记成一句话：DecodeConfig 负责决定是否值得继续，Decode 负责在允许后构造完整图像。

相关问题

DecodeConfig 会返回图片像素吗？

不会。它返回 image.Config，重点是颜色模型、宽度和高度；要得到 image.Image 仍需调用 Decode。

只做 DecodeConfig 就能确认图片完全有效吗？

不能。它完成的是配置阶段读取，完整数据、IDAT 内容和后续校验仍可能在 Decode 阶段失败。

为什么第二次 Decode 还要重新创建 Reader？

因为第一次读取已经推进了 Reader。文件可以重新打开，字节切片可以用新的 bytes.NewReader，不可回退的网络流则需要先保存到受控的可重复输入。