Go image.DecodeConfig 不解码像素怎样先判断图片尺寸

接收用户上传图片时，直接调用 image.Decode 不是最稳妥的入口：解码器可能按照图片头部的宽高申请与像素数量相关的内存。Go 标准库提供了 image.DecodeConfig，它先读取已注册格式的头部，返回 image.Config、格式名和错误，不创建完整的像素图。实用做法是：把输入保存成可重读的 Reader，先检查宽高和像素预算，通过后再调用 image.Decode。

DecodeConfig 先读什么，为什么还没有像素图

image.DecodeConfig 的返回值是 (image.Config, string, error)。其中 Config.Width 和 Config.Height 是尺寸，Config.ColorModel 是颜色模型，第二个返回值是注册时使用的格式名，例如 jpeg 或 png。它不会返回可以调用 At 的 image.Image。

标准库先把 Reader 包装成可窥视头部的读取器，再根据已注册格式的 magic 前缀选择解码器。image/png、image/jpeg、image/gif 常见的匿名导入，就是让各自的 init 调用 image.RegisterFormat。缺少对应导入时，图片内容即使正确，也可能得到 image: unknown format。

用同一份可重读输入完成尺寸预检

如果上传内容在内存中，可以先保存为 []byte，每次调用都创建新的 bytes.Reader。这样既不会依赖 Reader 的当前位置，也不会误以为 DecodeConfig 已经把所有内容读完。文件场景也可以先打开文件、记录当前位置，或者重新打开文件；不要把一次性网络流在预检后直接交给第二个解码阶段。

package main

import (
	"bytes"
	"fmt"
	"image"
	_ "image/gif"  // 通过 init 注册 GIF 的 DecodeConfig 和 Decode。
	_ "image/jpeg" // 通过 init 注册 JPEG 的格式识别器。
	_ "image/png"  // 通过 init 注册 PNG 的格式识别器。
)

const maxPixels int64 = 20_000_000

func inspectAndDecode(data []byte) (image.Image, string, error) {
	// 预检和正式解码各用一个 Reader，避免共享读取位置。
	cfg, format, err := image.DecodeConfig(bytes.NewReader(data))
	if err != nil {
		return nil, "", fmt.Errorf("读取图片头部失败: %w", err)
	}
	// 转成 int64 后再相乘，避免窄整数平台上的乘法溢出。
	if int64(cfg.Width)  maxPixels {
		return nil, format, fmt.Errorf("图片像素数超过限制: %dx%d", cfg.Width, cfg.Height)
	}
	// 通过尺寸门槛后才创建完整 image.Image。
	decoded, decodedFormat, err := image.Decode(bytes.NewReader(data))
	if err != nil {
		return nil, decodedFormat, fmt.Errorf("正式解码失败: %w", err)
	}
	return decoded, decodedFormat, nil
}

这个示例的重点不是把所有输入永久放进内存，而是展示读取边界：当原始内容本来就在上传缓冲区时，bytes.Reader 让两个阶段拥有独立位置。若上传接口允许无限大的请求，还应在进入这段逻辑前限制原始字节数；像素预算和文件字节预算解决的是两种不同的资源风险。

像素预算要和格式、文件大小分开判断

宽高乘积是最容易落地的第一道门槛，但它不等于最终内存占用，也不等于压缩文件大小。不同格式、颜色模型和动画帧会影响解码成本；GIF 的逻辑屏幕尺寸通过预检，并不代表所有帧都适合一次性读入。因此生产代码应把尺寸检查、原始上传大小和业务允许的格式分成独立条件。

几个经常踩到的边界

第一，DecodeConfig 不是“只读固定几个字节”的统一承诺，具体格式仍可能读取足够解析头部的数据；它的关键保证是不会分配完整尺寸的像素缓冲。第二，返回的宽高应被当作不可信输入，乘法前先转成更宽的整数类型。第三，预检通过后图片仍可能在正式解码阶段因截断、格式错误或资源不足失败，不能只判断预检无错就返回成功。

如果 Reader 不能重读，先用受控方式缓存输入，或把数据落到临时文件后重新打开。不要通过“继续读取当前位置”来碰运气，因为格式解码器需要从图片开头重新识别 magic。对于网络上传，还要把请求体大小限制放在解码之前，避免为了取得尺寸而先接受无限输入。

常见问题

DecodeConfig 会返回 image.Image 吗？

不会。它返回 image.Config、格式名和错误；要访问像素或调用 Bounds，仍需通过 image.Decode 得到 image.Image。

DecodeConfig 通过后还需要检查 Decode 错误吗？

需要。预检主要读取配置头部，正文可能截断或损坏，正式解码仍必须检查错误并在失败时释放相关资源。

为什么明明导入了 image 包仍然识别不了 PNG？

仅导入 image 不会自动注册 PNG。需要匿名导入 _ "image/png"，让 PNG 包的初始化逻辑注册格式解码器。