正确读取BMP需先校验bfType为0x4D42，再依bfOffBits定位像素数据；行数据须按4字节对齐，且图像数据自底向上存储；位深与通道顺序须结合biBitCount和biCompression判断，结构体须用packed避免对齐错误。
怎么读取BMP文件头和位图信息头
直接用 fread 读 54 字节就能拿到标准 BMP 的文件头（BITMAPFILEHEADER）和信息头（BITMAPINFOHEADER），但必须校验 bfType 是 0x4D42（即 "BM"），否则不是合法 BMP。Windows BMP 常见但不保证是 54 字节——如果 biSize 大于 40，说明用了扩展头（比如带颜色空间或伽马信息），这时不能硬写死 54，得按 bfOffBits 偏移去读像素数据起始位置。
-
bfOffBits才是真正像素数据的起始偏移，它可能大于 54（例如含调色板时） - 32 位 BMP 没有调色板，
bfOffBits通常是 54；24 位同理；但 8 位 BMP 一定有 256 项调色板，占 1024 字节，bfOffBits就是 54 + 1024 = 1078 - 别用
sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER)算偏移——结构体可能因对齐填充变大，bfOffBits才是唯一可信值
怎么正确读取像素数据并处理行对齐
BMP 的每行像素字节数必须是 4 的倍数，不足就补 0（叫“行填充”）。比如宽度为 101 像素的 24 位图，每行真实需 101 × 3 = 303 字节，但磁盘上占 304 字节（补 1 个 0x00）。如果忽略这点，后续行数据会整体错位。
- 计算每行存储字节数：
(width * bits_per_pixel + 31) / 32 * 4（等价于向上取整到 4 字节对齐） - 读取时，每行按这个对齐长度读，但只取前
width * bytes_per_pixel字节作有效像素 - 注意：BMP 像素从左下角开始存，第一行数据对应图像最下面那行——要显示或处理成常规坐标，得把行顺序倒过来
怎么区分 24 位和 32 位 BMP 并提取 RGB/RGBA
看 biBitCount：24 表示 RGB 每通道 8 位，无 alpha；32 表示 RGBA，但 Windows 默认 alpha 为 0（不透明），且部分老工具生成的 32 位 BMP 其实没用 alpha，只是对齐需要。关键不是位数，而是 biCompression 是否为 BI_BITFIELDS（此时才有掩码定义通道布局）。
- 24 位：每像素 3 字节，顺序是 B、G、R（不是 RGB！）
- 32 位常见情况：B、G、R、A 顺序，但必须检查
biCompression == BI_RGB才能默认此顺序；若为BI_BITFIELDS，得读后面的 3 个掩码（dwRedMask等）确定 R/G/B/A 位置 - 很多所谓“32 位 BMP”其实是
BI_RGB+ 32biBitCount，此时第 4 字节常为填充位，不是 alpha——别直接当透明度用
遇到 Invalid BMP signature 或花屏怎么办
90% 是因为没校验 bfType 或误判了 bfOffBits，剩下 10% 是字节序或结构体对齐惹的祸。BMP 文件是小端序，但结构体在内存中受编译器对齐影响，pragma pack(2) 或 __attribute__((packed)) 必须加，否则 BITMAPFILEHEADER 读出来字段全错。
立即学习“C++免费学习笔记（深入）”；
- 先用十六进制查看器打开 BMP，确认开头确实是
42 4D（即 "BM"） - 打印出读到的
bfOffBits和实际文件大小，看是否超出范围 - 用
sizeof打印你定义的结构体大小，和 Windows SDK 中定义对比——如果不一致，说明没 pack，字段偏移全乱 - 调试时临时把每行像素 dump 成二进制，用 Python 快速验证：读出来的 BGR 数据用
numpyreshape 后 cv2.imshow，比肉眼盯 hex 更快定位错位点
真正麻烦的从来不是读数据，而是 BMP 格式本身留了太多历史缝隙：对齐规则、头结构变长、压缩标志歧义、alpha 存在性模糊……动手前先用 xxd -l 64 your.bmp 看前 64 字节，比查文档快十倍。
