因结构体含非POD成员（如std::string）、内存填充或未用binary模式，导致write()写入无效地址或字节错位。须用POD结构、#pragma pack(1)、固定数组、memset清零，并显式指定binary模式。
用 std::fstream 直接读写结构体数据，为什么常读出乱码或崩溃
因为 C++ 结构体默认是「非 POD 类型」或含对齐填充，直接 write() 内存块时，sizeof(MyStruct) ≠ 实际有效字段字节数，且不同编译器/平台的内存布局可能不一致。更关键的是：一旦结构体里有 std::string、std::vector 这类动态成员，它们只存指针，write() 出去的就是野地址。
- 必须用 POD（Plain Old Data）结构体：只含基本类型、数组、其他 POD 成员，无构造函数、虚函数、非 public 成员
- 显式加
#pragma pack(1)或alignas(1)消除填充字节（尤其跨平台时） - 禁止出现
std::string；改用固定长度字符数组，如char name[32] - 写入前用
memset(&obj, 0, sizeof(obj))清零，避免未初始化内存参与序列化
示例合法结构体：
struct Record {
int id;
char name[32];
double score;
} __attribute__((packed)); // GCC 方式，MSVC 用 #pragma pack(1)如何安全地追加记录并支持随机读取第 N 条
文件不是数据库引擎，没有索引，靠偏移计算定位是最直接方式 —— 但前提是每条记录长度严格固定。
- 先用
seekg(0, std::ios::end)获取文件总大小，再除以sizeof(Record)得到当前记录数 - 读第
n条：用seekg(n * sizeof(Record))跳转，再read()一个Record实例 - 写新记录：
seekp(0, std::ios::end)后直接write()，不要用append模式（它在某些标准库实现中行为不一致） - 务必检查
write()返回值是否等于sizeof(Record)，否则说明磁盘满或权限失败
错误示范：fstream.open("db.bin", ios::in | ios::out | ios::app) —— app 会强制所有写入都在末尾，且 seekp() 失效。
立即学习“C++免费学习笔记（深入）”；
删除某条记录时，为什么不能直接把后面的数据往前搬
可以搬，但代价高：每次删都要重写后面全部数据，O(N) 时间 + 频繁磁盘 IO。更实际的做法是「逻辑删除」+ 空间复用。
- 在结构体开头加一个
bool valid字段（或用特殊值如id == -1标记已删） - 插入新记录时，先 scan 文件找第一个
valid == false的空位，优先复用 - 如果找不到空位，再追加到末尾
- 定期提供
vacuum()手动整理：读出所有valid == true的记录，写入新文件，替换原文件（注意原子性：写完rename()替换）
注意：valid 字段本身也要参与 pack 对齐，否则结构体大小会因 padding 变化。
遇到 ios_base::failure 或读出全零数据，该查什么
这不是“文件打不开”那么简单，而是流状态机进入失败态后，后续所有操作都静默失败。
- 每次
read()/write()后立即检查if (!fs.good())或if (fs.fail())，而不是等最后统一判断 - 常见诱因：
seekg()超出文件末尾（返回pos_type(-1)），或read()请求长度超过剩余字节 - Windows 下路径含中文或空格易触发编码问题，优先用 UTF-8 编码路径（C++20
std::filesystem::u8path）或转义为短路径 - 调试时用
fs.tellg()打印当前位置，确认跳转是否成功；用fs.rdstate()查具体哪位标志置位
最易被忽略的一点：二进制模式必须显式指定 —— std::ios::binary 缺失会导致 Windows 下 \n 被误转成 \r\n，破坏结构体对齐。
