reinterpret_cast直接转结构体指针常出错，因结构体存在填充字节、非POD成员（如指针、string）、大小端不一致、对齐差异及虚函数导致vptr失效；仅标准布局且trivially copyable时才可能安全，但仍需校验偏移与对齐。
读取二进制文件时，reinterpret_cast 直接转结构体指针为什么常出错
因为结构体在内存中可能有填充字节（padding），而文件里存的字节流未必和当前编译器对齐方式一致；更关键的是，如果结构体含指针、std::string、std::vector 等非 POD 成员，直接 memcpy 会复制无效地址或悬垂指针，运行时崩溃几乎是必然的。
- 仅当结构体是标准布局（standard-layout）且所有成员都是 trivially copyable 时，
memcpy或reinterpret_cast才可能安全 —— 但“可能”不等于“推荐” - 用
offsetof检查字段偏移是否与文件格式一致，比盲目 cast 更可靠 - 跨平台读写时，大小端（endianness）必须显式处理，
ntohl/htons类函数不能少
fread 读到结构体数组后，如何避免野指针和内存泄漏
如果结构体里有动态分配字段（比如 char* 成员指向字符串），文件里通常只存长度+数据块，不能直接把整个 struct 当作一块内存读进来就完事。必须分步解析：先读固定头，再根据头里的长度字段去读后续变长部分。
- 不要用
new T[n]+fread(buf, sizeof(T), n, fp)一次性读 —— 这只适用于纯 POD 数组 - 每个结构体实例应单独 new，字段逐个反序列化：
int len; fread(&len, sizeof(len), 1, fp); char* s = new char[len+1]; fread(s, 1, len, fp); s[len] = '\0'; - 务必配对 delete[]，且在异常路径（如 fread 失败）也要清理已分配内存，否则泄漏
用 std::ifstream 的 read 方法读结构体，ios_base::binary 不开会怎样
不开就是文本模式：Windows 下 \r\n 自动转 \n，读取字节数错乱；Linux 虽无换行转换，但某些 libc 实现仍可能因缓冲策略导致 read 返回字节数少于预期，尤其读取小块数据时。
- 必须在 open 后立即调用
file.open("xxx", std::ios::binary)或构造时传入 flag - 检查
gcount()确认实际读取字节数，别只信返回值：file.read(buf, size); if (file.gcount() != size) { /* 错误处理 */ } - 用
file.peek() == EOF判断是否读完，而不是依赖file.eof()—— 它只在尝试读失败后才置位
结构体含虚函数或继承关系时，绝对不能直接反序列化
虚表指针（vptr）是运行时由编译器注入的，文件里不可能存这个地址；若强行还原，对象调用虚函数时会跳转到随机内存，大概率 segfault。
立即学习“C++免费学习笔记（深入）”；
- 含虚函数的类不是 trivially copyable，
std::is_trivially_copyable_v<t></t>为 false，编译期就能拦住部分错误 - 必须用序列化协议替代：比如按字段名/类型/长度写成自描述格式（JSON/Binary Protocol Buffer），再重建对象
- 即使只是多态基类，也得靠工厂函数 + 类型 ID 字段来决定 new 哪个子类，不能靠内存布局还原
最易被忽略的一点：结构体对齐（alignas）和打包（#pragma pack）必须和写入方完全一致，否则同一个 uint64_t 字段在读写两端可能落在不同偏移上 —— 这种错不会报错，只会静默读错数据。
