Go image.DecodeConfig 如何只读图片尺寸：格式探测、流位置与大文件边界

上传服务常见一个小判断：文件是不是支持的图片、宽高是否超过限制。只做这个判断时，直接调用 image.Decode 会把工作推进到像素解码；更合适的入口通常是 image.DecodeConfig。它先返回 Config，让代码读取 Width 和 Height，但不会因此替你完成文件大小、后缀或资源上限检查。

把“读取图片元数据”和“解码整张图片”分开：尺寸门禁用 image.DecodeConfig，确实要处理像素时再调用 image.Decode，并且为输入设置独立的大小边界。

只验尺寸时，为什么先选 image.DecodeConfig

image.Config 是图片的轻量描述，包含颜色模型和宽高。image.DecodeConfig 接收一个 io.Reader，由已注册的格式解码器探测输入并返回配置。对头像、缩略图入口这类“先判断能不能收”的请求，读出 Width、Height 后即可做业务门禁，不必马上创建完整的 image.Image。

func acceptSize(r io.Reader, maxWidth, maxHeight int) (image.Config, error) {
    cfg, err := image.DecodeConfig(r)
    if err != nil {
        return image.Config{}, err
    }
    if cfg.Width > maxWidth || cfg.Height > maxHeight {
        return image.Config{}, fmt.Errorf("image dimensions exceed limit")
    }
    return cfg, nil
}

这里的判断只代表“配置里的尺寸没有超过业务阈值”。它不代表内容一定安全，也不代表读取的字节数有限；文件体积和请求体上限仍应在更外层控制。

格式探测走哪条链：image.DecodeConfig、Config 与注册格式

标准库的关系可以压缩成一条可核对的链：image.DecodeConfig 读取 io.Reader，格式探测命中已注册的解码配置函数后返回 Config，调用方再读取 Width 和 Height。只看文件名后缀不在这条链上，所以把 .jpg 改名为别的后缀不会改变真实字节格式。

如果程序没有导入并注册对应格式，探测可能失败。JPEG 场景通常需要导入 image/jpeg 以完成格式注册；实际服务应把支持的格式和依赖写成明确的构建约定，而不是根据用户后缀猜测。

同一个 Reader 连续调用时，流位置是关键

image.DecodeConfig 消费的是 io.Reader。文件流、网络流和内存缓冲的读取位置都可能发生变化，因此不能把同一个 Reader 先交给配置探测，再无条件交给完整解码，并假设第二次仍从文件头开始。

f, err := os.Open("avatar.jpg")
if err != nil {
    return err
}
defer f.Close()

cfg, err := image.DecodeConfig(f)
if err != nil {
    return err
}
if cfg.Width > 4096 || cfg.Height > 4096 {
    return fmt.Errorf("image dimensions exceed limit")
}

if _, err := f.Seek(0, io.SeekStart); err != nil {
    return err
}
img, _, err := image.Decode(f)
if err != nil {
    return err
}
_ = img

上面的 Seek 只适合可定位的文件或内存文件。若输入来自不可回退的网络流，应该在边界允许的前提下缓存字节，或把“配置探测”和“完整解码”设计成一次消费流程，而不是偷偷重复读取。

三个边界别混在一起：格式、尺寸和字节数

• 格式边界：DecodeConfig 报错时，可能是格式不支持或数据不完整；不要用扩展名把错误改写成成功。
• 尺寸边界：Config.Width 与 Config.Height 适合做像素尺寸门禁，阈值要结合业务内存预算。
• 字节边界：Reader 读多少字节由输入和解码器决定，上传服务仍要限制请求体和临时文件大小。

如果后续要做旋转、缩放或像素分析，才进入 image.Decode。这时应重新审视解码产生的内存、超大尺寸图片和异常输入，而不是把 DecodeConfig 当作完整安全检查。

实际选择：先探测，还是直接完整解码

只需拒绝超大图片时选 image.DecodeConfig；需要像素内容时选择“先探测再完整解码”，但为可回退的 Reader 处理位置；数据来自不可回退流且只允许一次消费时，缓存策略必须和大小上限一起设计。这个取舍比“所有图片都先 Decode”更容易解释，也更容易在压测和故障日志里定位。

相关问题

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

不会。它返回的是 image.Config 和错误；需要像素对象时才调用 image.Decode。

只改文件后缀能绕过格式判断吗？

不能。格式探测基于 Reader 中的格式数据，后缀只是业务层可选的提示。

DecodeConfig 能替代上传大小限制吗？

不能。尺寸是像素维度，字节数是输入体积，两者必须分别设限。

为什么第二次 Decode 读不到文件头？

因为 Reader 的当前位置可能已被 DecodeConfig 推进；可定位流应回到开头，不可定位流则要提前规划缓存或单次消费。

小结

image.DecodeConfig 适合把图片接收流程拆成“格式与尺寸门禁”和“像素处理”两段。记住 io.Reader 的消费语义，再分别限制尺寸与字节数，代码的行为就不会被文件后缀或一次成功探测掩盖。