Go png.DecodeConfig 怎么只读取 PNG 尺寸再决定是否解码

如果只想判断 PNG 是否过大，直接调用 png.Decode 会先创建完整的 image.Image，这一步通常没有必要。更合适的做法是先调用 png.DecodeConfig，取得 image.Config 中的宽度、高度和颜色模型；只有通过尺寸策略后，才继续完整解码。

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

需要注意的是，DecodeConfig 只解决“能否进入完整解码”的预读问题，不会替你返回 image.Image，也不能保证后续完整解码一定成功。文件输入还要处理 Reader 位置；非可回退的流则应先缓存，或把预读和完整读取拆成两个输入。

先用 DecodeConfig 取得 PNG 配置

最小调用只需要一个 io.Reader。返回的 image.Config 包含 Width、Height 和 ColorModel，它适合做尺寸上限、颜色模型兼容性等轻量判断。

package main

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

func main() {
    f, err := os.Open("input.png")
    if err != nil {
        panic(err)
    }
    defer f.Close() // 文件句柄只由当前函数负责关闭

    cfg, err := png.DecodeConfig(f)
    if err != nil {
        panic(err) // 配置读取失败时，不继续尝试完整解码
    }

    fmt.Printf("%dx%d %v\\n", cfg.Width, cfg.Height, cfg.ColorModel)
}

这里的结果是配置，不是完整图像。也就是说，读者可以在这一步拒绝过大的图片，避免把不符合资源预算的输入交给 png.Decode。

尺寸和颜色模型应该怎样参与判断

准入规则最好先写成明确的业务约束，再映射到 cfg。例如头像服务只接受最长边不超过 4096 像素，并且暂时只允许灰度或 RGBA 输入。判断失败时直接返回普通错误，成功后才执行下一阶段。

func acceptPNG(cfg image.Config) error {
    const maxSide = 4096

    // 先拒绝非法或超出资源预算的尺寸，避免进入完整解码。
    if cfg.Width  maxSide || cfg.Height > maxSide {
        return fmt.Errorf("PNG is too large: %dx%d", cfg.Width, cfg.Height)
    }

    // 颜色模型是预读信息的一部分；这里示范只允许灰度和 RGBA。
    switch cfg.ColorModel {
    case color.GrayModel, color.Gray16Model, color.RGBAModel, color.NRGBAModel:
        return nil
    default:
        return fmt.Errorf("unsupported color model: %v", cfg.ColorModel)
    }
}

这段代码需要补充 fmt、image 和 image/color 导入。示例重点是边界顺序：先判断整数尺寸，再判断颜色模型；不要把预读结果误当作已经完成了像素级处理。

为什么 DecodeConfig 后不能直接假设 Reader 还在开头

png.DecodeConfig 需要从输入中读取 PNG 的配置数据，因此对文件或内存 Reader 的当前位置会产生影响。若随后直接把同一个 Reader 传给 png.Decode，它看到的可能已经不是文件开头，结果就可能报格式错误或读不到完整内容。

可定位的文件应在预读通过后用 Seek(0, io.SeekStart) 回到开头：

func decodeCheckedFile(path string) (image.Image, error) {
    f, err := os.Open(path)
    if err != nil {
        return nil, fmt.Errorf("open PNG: %w", err)
    }
    defer f.Close() // 无论预读还是完整解码如何返回，都释放文件句柄

    cfg, err := png.DecodeConfig(f)
    if err != nil {
        return nil, fmt.Errorf("read PNG config: %w", err)
    }
    if err := acceptPNG(cfg); err != nil {
        return nil, err
    }

    // DecodeConfig 已经消费了一部分输入，完整解码前必须回到开头。
    if _, err := f.Seek(0, io.SeekStart); err != nil {
        return nil, fmt.Errorf("rewind PNG: %w", err)
    }
    img, err := png.Decode(f)
    if err != nil {
        return nil, fmt.Errorf("decode PNG: %w", err)
    }
    return img, nil
}

这个方案适合普通文件，因为 *os.File 支持定位。Seek 失败时必须停止，不要把当前未知位置的 Reader 继续交给解码器。

非 Seek 流应该缓存后创建两个 Reader

网络响应、管道或其他只实现 io.Reader 的输入通常不能回退。此时不要强行断言它支持 io.Seeker，可以一次读入字节切片，再分别创建两个 bytes.Reader。代价是需要承担输入文件大小对应的内存占用。

func decodeCheckedBytes(r io.Reader) (image.Image, error) {
    data, err := io.ReadAll(r)
    if err != nil {
        return nil, fmt.Errorf("buffer PNG: %w", err)
    }

    // 两个 Reader 互不共享当前位置，预读不会影响完整解码。
    cfg, err := png.DecodeConfig(bytes.NewReader(data))
    if err != nil {
        return nil, fmt.Errorf("read PNG config: %w", err)
    }
    if err := acceptPNG(cfg); err != nil {
        return nil, err
    }

    img, err := png.Decode(bytes.NewReader(data))
    if err != nil {
        return nil, fmt.Errorf("decode PNG: %w", err)
    }
    return img, nil
}

这个版本需要导入 bytes、fmt、image 和 image/png。如果输入可能很大，先做传输层大小限制，或者落到临时文件后采用可定位文件方案；不要因为 DecodeConfig 很轻量，就忽略缓存本身的成本。

把“预读成功”和“完整解码成功”分成两层错误

第一层错误表示输入不是可接受的 PNG，或者配置阶段无法读取；第二层错误表示配置通过，但完整像素数据仍然解码失败。两层错误应该保留不同的上下文，日志和调用方才能知道问题发生在哪个边界。

因此，DecodeConfig 更像是一次低成本的准入检查，而不是完整文件验收。即使配置阶段成功，也应继续处理 png.Decode 的错误。

落地时的简明清单

• 先调用 png.DecodeConfig，用宽高和颜色模型决定是否继续。
• 文件 Reader 在第二次读取前调用 Seek(0, io.SeekStart)，并处理定位错误。
• 不可回退的流使用字节缓存和两个独立的 bytes.Reader，同时设置输入大小上限。
• 分别包装配置读取错误和完整解码错误，不把两阶段混成一个“图片无效”。
• 资源句柄由打开它的函数关闭；完整解码成功也不意味着可以跳过业务层的尺寸约束。

相关问题

DecodeConfig 会返回完整的 image.Image 吗？

不会。它返回的是 image.Config，主要用于取得颜色模型和尺寸；需要像素数据时仍要调用 png.Decode。

为什么 DecodeConfig 后 Decode 可能读不到内容？

因为两个函数共享同一个 Reader 时，前一个函数已经推进了读取位置。可定位输入要回到开头，不可定位输入要重新创建 Reader。

只检查宽高就足够安全吗？

不够。宽高是资源准入的一部分，颜色模型、输入总大小和后续完整解码仍需按业务场景处理。