用fread读结构体前必须确保写入端与读取端结构体定义、内存布局及文件打开模式完全一致，否则会导致数据错乱或崩溃；需禁用对齐优化、避免指针字段、使用"rb"模式并检查返回值。
用 fread 读结构体前，必须确保内存布局一致
二进制文件里存的不是“结构体”，而是字节流；fread 只是把一串字节原样拷进内存。如果写入和读取时结构体定义不一致（比如字段顺序、类型大小、对齐方式不同），读出来的数据就错乱——哪怕编译通过也毫无意义。
常见错误现象：fread 返回值正常，但结构体里某个 int 字段值是 0x12345678 变成 0x78563412，或字符串字段开头是乱码。
- 写入和读取两端必须用完全相同的结构体定义（建议用头文件统一管理）
- 禁用编译器自动对齐优化：在结构体声明前后加
#pragma pack(1)，否则不同平台/编译器默认对齐可能差几个字节 - 避免使用位域、柔性数组成员（
char data[]）等非标准布局特性 - 跨平台时特别注意
long、size_t大小不一致，改用int32_t等固定宽度类型
fread 的参数陷阱：别只看数量，要盯紧单位
fread(ptr, size, nmemb, stream) 的第二、三参数容易被当成“读多少字节”，其实它读的是 nmemb 个、每个 size 字节的块。结构体读取时最常错在这里。
使用场景：想读一个 struct record，大小是 24 字节。
立即学习“C语言免费学习笔记（深入）”；
- ✅ 正确：
fread(&r, sizeof(r), 1, fp)—— 读 1 个、大小为sizeof(r)的块 - ❌ 错误：
fread(&r, 1, 24, fp)—— 读 24 个字节，但fread可能因换行符或 EOF 提前返回 23，且无法判断是否读满 - ❌ 更危险：
fread(&r, sizeof(struct record), 10, fp)—— 想读 10 条，但没检查返回值，实际只读了 7 条却继续用未初始化的内存
务必检查返回值：size_t n = fread(&r, sizeof(r), 1, fp); if (n != 1) { /* 文件结束或出错 */ }
结构体含指针字段？fread 直接失效
结构体里有 char *、void * 或其他指针成员时，fread 会把指针地址本身（比如 0x7fff12345678）当二进制数据读进来。这个地址在当前进程里无效，解引用必崩。
常见错误现象：程序运行时 Segmentation fault，gdb 显示崩溃在访问 r->name[0]。
- 指针字段不能直接用
fread恢复，必须拆解：先读基础字段，再根据长度字段分配内存，最后单独读字符串/数组内容 - 例如结构体含
uint32_t len; char *data;，需先读len，再malloc(len)，再fread(ptr->data, 1, len, fp) - 如果原始写入也没处理指针（比如只写了
sizeof(struct)而跳过data区域），那根本没法恢复——二进制文件里压根没存那些数据
文件打开模式必须是 "rb"，Windows 下尤其关键
文本模式（"r"）在 Windows 上会把 \r\n 自动转成 \n，导致所有后续字节偏移错乱。哪怕文件里全是数字，只要用 "r" 打开，fread 就可能少读或多读字节。
错误信息示例：fread 返回值比预期小，但 ferror(fp) 为 0、feof(fp) 也不为真——其实是文本模式悄悄吃了换行符。
- ✅ 唯一安全写法：
FILE *fp = fopen("data.bin", "rb"); - Linux/macOS 虽然对文本/二进制模式区别小，但为了可移植性，一律用
"rb"和"wb" - 用
od -x data.bin | head对比原始文件十六进制和实际读到的内容，能快速定位是否被文本模式污染
结构体二进制读写的真正难点不在语法，而在于两端定义、内存布局、I/O 模式这三点必须严丝合缝。漏掉任何一环，数据就不可逆地损坏了。
