用 fread 按字节读二进制文件最省事，但需确保读写端结构体定义、对齐（如 #pragma pack）、编译器及平台一致；含指针、跨平台或非纯结构体数据时，应分段读取并处理字节序与边界。
用 fread 按字节读取二进制文件，结构体对齐必须和写入端一致
直接 fread 读进结构体变量，最省事，但前提是：你读的文件是用相同编译器、相同结构体定义、相同对齐设置（比如 #pragma pack 或 _Alignas）写出来的。否则字段错位、数值全乱，连 sizeof(struct) 都可能不匹配。
- 检查写入端是否用了
#pragma pack(1)—— 如果用了，读取端也得加，否则默认 4 字节对齐会插填充字节 - 结构体里有指针？别读了，二进制文件存的是地址值，读到另一进程里毫无意义
- 跨平台（比如 Windows 写、Linux 读）时，注意
int大小、字节序（little-endian vs big-endian），uint32_t比int更可靠 - 示例：假设结构体
struct { uint16_t id; uint32_t len; char data[64]; }，写入前确认sizeof是 70（非 72）才敢用pack(1)
手动逐字段读取更可控，适合协议解析或格式不固定场景
当文件不是“纯结构体 dump”，而是带魔数、长度头、变长字段时，硬塞进一个结构体反而容易崩溃。这时候用 fread 分段读，自己控制偏移和类型转换，更稳妥。
- 先读 4 字节魔数：
uint32_t magic;→fread(&magic, 1, 4, fp);，再用ntohl(magic)转换字节序 - 接着读长度字段，再按该长度动态分配内存读 payload，避免栈溢出或越界
- 读字符串字段时，别直接往
char buf[256]里读 —— 先读长度，再限制fread(buf, 1, len, fp)，最后补\0 - 错误现象：读出来字符串乱码、数字异常大 —— 很可能是没处理字节序，或把无符号字段当有符号用了
fread 返回值不等于请求字节数，说明出问题了，不能只看 feof
fread 返回实际读到的**元素个数**（不是字节数！），如果调用是 fread(buf, sizeof(uint8_t), 1024, fp)，它返回小于 1024 就意味着提前结束或出错，此时要立刻查 ferror(fp) 和 feof(fp)，而不是继续解析。
- 常见坑：用
while (!feof(fp))循环读 ——feof只在尝试读失败后才置位，最后一轮会重复处理上一次成功读的数据 - 正确做法：
size_t n = fread(buf, 1, BUFSIZ, fp);，然后if (n == 0) break;，再判断n 是否因文件尾或错误导致 - 二进制文件末尾没有换行或特殊标记，依赖
feof判断“读完”极易多读或少读一帧
结构体含浮点字段时，读取后需验证 isnan / isinf，尤其跨平台传输
IEEE 754 浮点数在内存中是确定的，但不同平台对非规格化数、NaN 的处理可能不同；如果写入端是嵌入式设备（比如 ARM Cortex-M），而读取端是 x86_64，某些极端值可能被解释为非法指令或触发 SIGFPE。
立即学习“C语言免费学习笔记（深入）”；
- 读完
float f;后加一句if (isnan(f) || isinf(f)) { /* 记录警告或跳过 */ } - 避免用
==直接比较读出的浮点字段，尤其是从网络或文件来的原始 bit —— 有些旧设备会把未初始化浮点字段填成 0xFF...，读出来就是 quiet NaN - 如果协议允许，优先用整型缩放存储（如
int32_t temp_x100表示摄氏度 ×100），彻底绕开浮点兼容性问题
事情说清了就结束。最麻烦的从来不是怎么读，而是怎么确认你读到的，确实是对方写进去的那个“东西”。
