必须先读 BITMAPFILEHEADER 检查 bfType 是否为 0x4D42，再读 BITMAPINFOHEADER 并依 biSize 动态确定其长度，仅当 biBitCount ≤ 8 时存在调色板，其起始位置由 bfOffBits 减去文件头与 DIB 头总长得出。
怎么读取 BMP 文件头和 DIB 头里的调色板偏移与位数
BMP 的调色板（color table）不是固定存在的——只有 biBitCount ≤ 8 时才可能有，且位置由 bfOffBits 决定，不是紧挨着 DIB 头。很多人直接跳过文件头、硬算偏移，结果一读就乱码。
实操建议：
- 必须先用
fread读入BITMAPFILEHEADER（14 字节），检查bfType是否为0x4D42（即'BM'），否则不是合法 BMP - 再读
BITMAPINFOHEADER（40 字节），重点看biBitCount：值为 1/4/8 才有调色板；16/24/32 时bfOffBits指向像素数据起始，调色板不存在 -
bfOffBits是从文件开头到像素阵列的字节偏移，它 = 14 + DIB 头长度 + 调色板字节数；DIB 头长度不总是 40（可能是 52、56、108 等），得用biSize动态读取 - 调色板条目数 =
1 （仅当 ≤ 8），每项 4 字节（BGRX 或 BGRA，注意 X 是填充字节，不参与显示）
为什么调色板 RGB 值要手动翻转字节顺序
Windows BMP 规定调色板每项是 RGBQUAD 结构：rgbBlue、rgbGreen、rgbRed、rgbReserved，按此顺序存为 4 字节。但内存里直接读出来是 BGR 排列，直接当 RGB 用会严重偏色。
常见错误现象：红色物体显示成青色，绿色变品红——就是没交换 rgbBlue 和 rgbRed。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 别用
reinterpret_cast整块映射RGBQUAD*后直接取.rgbRed；结构体对齐和字节序容易出问题 - 安全做法：把每个调色板项当作
uint8_t[4]读，然后手动赋值：r = quad[2]; g = quad[1]; b = quad[0]; - 注意：有些老 BMP（OS/2 格式）用的是
RGBTRIPLE（3 字节），无保留位，此时bfOffBits和调色板解析逻辑完全不同，需先判biSize是否为 12
像素阵列怎么按行倒序读、还要考虑行字节对齐
BMP 像素数据从下到上存储（bottom-up），第 0 行是图像最底一行；而且每行字节数必须是 4 的倍数，不足则补 0。这两点不处理，图会镜像翻转 + 右侧出现杂色条带。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
使用场景：想把像素转成 OpenGL 纹理或 OpenCV Mat，必须还原为 top-down 且去除补零字节。
实操建议：
- 计算每行原始字节数：
row_size = ((biWidth * biBitCount + 31) / 32) * 4；这是含填充的字节数 - 跳到
bfOffBits开始读，每次读row_size字节，共读biHeight行 —— 但这是从底向上存的，所以第 i 行实际对应最终图像的biHeight - 1 - i行 - 若需 top-down 数据，可分配目标缓冲区后反向拷贝：
memcpy(dst + i * pitch, src + (height-1-i) * row_size, width_bytes) - 对于 24 位图，
width_bytes = biWidth * 3，而pitch = row_size，务必区分两者，别用pitch当真实像素宽度
遇到 16 位 BMP（555/565）怎么避免位域解析翻车
16 位 BMP 没调色板，像素直接编码颜色，但分 BI_BITFIELDS（掩码方式）和 BI_RGB（默认 555 或 565）。很多代码硬写位移，却忽略 biCompression 字段，导致 565 图被当 555 解，绿色过曝。
性能影响：用查表法预生成 16→24 位映射表比运行时位运算快 3–5 倍，尤其处理大图时。
实操建议：
- 先检查
biCompression == BI_BITFIELDS，若是，则接下来 3 个uint32_t是 R/G/B 掩码，需用__builtin_popcount或查表算有效位数和偏移 - 若
biCompression == BI_RGB，再看biBitCount == 16：Windows 默认用 555（高 1 位弃用），但常见硬件/导出工具用 565；稳妥做法是读文件末尾是否有 BITFIELDS 掩码块（部分程序会写进去） - 不要手写
(pixel & 0x7C00) >> 10这类硬编码——先确认格式，再生成对应 LUT；565 的 G 位是 6 位，占 0x7E0，不是 0x3E0
调色板和像素解析真正麻烦的不是读，而是 BMP 格式本身存在多个历史变种、字段含义随上下文漂移。哪怕 biSize 是 40，也不能默认 DIB 头后紧跟调色板——得靠 bfOffBits 为准，再减去已读字节数，才是调色板起点。这点最容易被忽略。
