不能直接用 fopen + fread 读整个文件，因为大图（如50MB TIFF/高清WebP）会浪费内存和时间；高效做法是只读文件头，如JPEG中扫描SOI（0xFFD8）后跳过APPn段，找到SOF0（0xFFC0）再取其后第5–8字节的宽高（大端）。
为什么不能直接用 fopen + fread 读整个文件？
很多人第一反应是“把图片文件全读进内存，再用 OpenCV 或 stb_image 解码”，这在小图上可行，但遇到 50MB 的 TIFF 或高清 WebP 就卡住——你只是想拿宽高比，不是要渲染它。真正高效的做法是只读文件头（header），跳过像素数据。不同格式的头结构差异大，但关键字段位置固定，且通常在前几百字节内。
JPEG 文件：用 jpeg_read_header 还是手动解析 SOI/APP0/SOF0？
OpenCV 的 cv::imread 必须解码整张图；libjpeg 的 jpeg_read_header 虽然快，但仍需初始化解码器、设置错误处理，对“只查尺寸”来说太重。更轻量的是手动扫描 JPEG 标记：找 0xFFD8（SOI）开头，然后跳过 APPn 段（0xFFE0–0xFFEF），直到遇到 0xFFC0（SOF0），其后第 5–6 字节是高度，第 7–8 字节是宽度（大端）。注意：必须检查标记长度字段，避免误判。
常见错误：
• 把 APP1（EXIF）当 SOF0，导致读出乱值
• 忽略标记长度字段，直接硬偏移，遇到带缩略图的 JPEG 就崩
• 没验证 SOI 开头，把非 JPEG 文件当 JPEG 解析
- 只读前 1024 字节足够覆盖绝大多数 JPEG 头
- 遇到
0xFFC0后，确认下一位不是0xFF（防伪标记） - 高度/宽度是 16 位大端，用
(buf[i] 提取
PNG 文件：靠 IHDR 块定位，别信 png_get_IHDR
libpng 的 png_get_IHDR 需要完整初始化 png_struct，启动成本高。PNG 文件头固定为 8 字节 \x89PNG\r\n\x1a\n，之后是多个 chunk，IHDR 必为第一个有效 chunk（规范强制）。它的长度字段（前 4 字节）为 13，类型字段（第 5–8 字节）为 IHDR，紧接着 4 字节宽度、4 字节高度（均为大端）。
立即学习“C++免费学习笔记（深入）”；
实操要点：
• 从 offset 8 开始，每次读 8 字节（4 字节长度 + 4 字节类型），判断是否为 IHDR
• 宽度在 IHDR 块起始 + 8 处，高度在 + 12 处
• 不需要 CRC 校验——你只关心头，CRC 在块末尾，跳过即可
- 如果文件被截断或损坏，
IHDR找不到就返回失败，别 fallback 到解码 - 某些工具生成的 PNG 可能有 zTXt 等前置 chunk，但规范要求
IHDR必须第一，可放心依赖 - 不支持 APNG（动画 PNG），其头结构不同，需额外识别
acTL块
通用方案：用 std::ifstream 配合 seekg 和 read，别用 C 风格 FILE*
C++ 标准库的 std::ifstream 支持二进制定位和局部读取，比 fopen+fseek 更安全（自动处理文本模式换行符干扰）。关键不是“能不能”，而是“读多少、在哪停”。一个健壮的函数应该：
- 以
std::ios::binary打开，禁用任何转换 - 先读前 16 字节判断 magic（
\xff\xd8、\x89PNG、GIF87a/GIF89a） - 按格式分支，各自实现最小必要解析逻辑，单个函数不超过 50 行
- 所有路径必须有超时/长度保护，比如 JPEG 解析循环最多走 10 次标记跳转
容易被忽略的是 GIF：它的逻辑屏幕描述符在文件头后第 6–13 字节，宽高各 2 字节，但要注意低版本 GIF 可能无扩展块，而新版可能有 NETSCAPE2.0 扩展，不过逻辑屏幕宽高永远在固定 offset。
复杂点在于 WebP：它有 RIFF 头，子块可能是 VP8（有帧头）、VP8L（带宽高字段）或 VP8X（扩展标志），必须先读 VP8X 判断是否含 canvas_width 字段，再决定怎么算——这里没标准库能绕开，得手撸解析。真要支持 WebP，建议直接用 WebPGetInfo（libwebp 提供），它内部也是只读头，但封装可靠。
