BITMAPFILEHEADER 宽高为0是因结构体对齐导致字段偏移错乱，需用#pragma pack(2)确保14字节；biHeight可正可负，表示图像原点位置，宽高取绝对值；行宽需DWORD对齐。
读取 BMP 文件头时为什么 BITMAPFILEHEADER 读出来宽高总是 0？
因为没处理结构体对齐，编译器自动加了填充字节，导致后续字段（比如 bfOffBits、biWidth）位置偏移，直接 fread 到结构体里就全乱了。
Windows BMP 的文件头是严格按 2 字节对齐的，但现代 C++ 编译器默认按自然对齐（如 4 或 8 字节），sizeof(BITMAPFILEHEADER) 很可能变成 16 而不是标准的 14。
- 用
#pragma pack(2)包住头结构体定义，读之前必须生效 - 别依赖
sizeof推算偏移，BMP 规范里BITMAPFILEHEADER固定 14 字节、BITMAPINFOHEADER固定 40 字节 - 读完立刻用
offsetof验证关键字段地址，比如biWidth应该在BITMAPINFOHEADER偏移 4 处
fread 读 BITMAPINFOHEADER 后 biWidth/biHeight 是负数？
BMP 的 biHeight 可正可负：正数表示倒序位图（原点在左下），负数表示正序（原点在左上）。很多工具生成的是负高度，但宽高本身取绝对值即可 —— 真正影响像素数据布局的是这个符号。
-
biWidth永远为正；biHeight符号决定扫描行顺序，不参与尺寸计算 - 实际图像宽度 =
abs(biWidth)，高度 =abs(biHeight) - 注意
biBitCount：24 位 BMP 每像素 3 字节，但每行字节数必须是 4 的倍数（补 0 到 DWORD 对齐），所以真实行宽 =((biWidth * biBitCount + 31) / 32) * 4
怎么安全提取像素数据而不越界或错位？
不能直接从文件头后第 bfOffBits 字节开始 memcpy，因为 bfOffBits 是相对文件开头的偏移，且它本身可能被错误解析（见第一个问题）；更稳妥的是手动跳过头 + 信息头，再校验 bfOffBits 是否合理。
立即学习“C++免费学习笔记（深入）”；
- 先读
BITMAPFILEHEADER，确认bfType == 0x4D42（即 'BM'） - 再读
BITMAPINFOHEADER，检查biSize == 40，避免遇到 OS/2 格式等变种 - 用
bfOffBits - sizeof(BITMAPFILEHEADER) - sizeof(BITMAPINFOHEADER)算出调色板长度（如果biBitCount ），再据此确定像素起始位置 - 读像素时按“行宽 × 高度”分配内存，别信
bfSize—— 它常被设为 0 或错误值
用 std::ifstream 二进制读取时为什么某些平台读不到完整数据？
没设 std::ios::binary 模式。Windows 下默认文本模式会把 \r\n 当成换行并悄悄转成单个 \n，而 BMP 文件里任何字节都可能是 0x0D 或 0x0A，一转就彻底破坏结构。
- 打开文件必须写：
std::ifstream file("a.bmp", std::ios::binary) - 用
file.read(reinterpret_cast<char>(&header), sizeof(header))</char>，别用operator>>或getline - 读完检查
file.gcount() == sizeof(header)，否则说明文件损坏或读取失败
结构体对齐不是编译选项开关，而是和每个字段排布强绑定的细节；哪怕你只读宽高，一旦对齐错了，biWidth 就可能落在前一个字段的填充区里，读出来的就是垃圾值。真要省事，不如直接按字节偏移手撸解析 —— BMP 头部就那么几十个字节，比调试对齐问题快得多。
