c++oding="utf-8" ?>
直接用 std::ofstream 配合 ios::app 追加写结构体数组是错误的，因 ios::app 会忽略字节对齐、结构体填充及已有数据长度，且与 ios::binary 组合时可能引发未定义行为；正确做法是用 ios::binary | ios::in | ios::out 模式打开文件，手动 seekp(0, ios::end) 后 write，并确保结构体为 POD 类型、显式控制对齐、校验 standard_layout 和 trivially_copyable。
直接用 std::ofstream 配合 ios::app 追加写结构体数组是错的
二进制文件追加结构体数组，不能简单地打开文件时加 ios::app 然后调用 write() —— 因为 ios::app 强制每次写入都定位到文件末尾，但会忽略当前文件的字节对齐、结构体填充（padding）和已有数据长度，极易导致读取时错位。更关键的是：ios::app 与二进制模式（ios::binary）组合使用时，在某些标准库实现中（如 libstdc++）可能触发未定义行为或静默截断。
正确做法：手动 seekg + write，且必须用 ios::binary
追加的本质是「定位到末尾再写」，但得自己控制偏移量，而不是依赖 ios::app。核心步骤是：
- 以
ios::binary | ios::in | ios::out模式打开文件（必须可读可写） - 用
seekp(0, ios::end)主动跳转到末尾 - 调用
write()写入结构体数组原始内存 - 注意：结构体必须是 POD 类型（无虚函数、无非平凡构造/析构、成员全为 public 简单类型），否则
reinterpret_cast<char></char>是未定义行为
示例（假设结构体 Record 是 POD）：
struct Record {
int id;
double value;
char name[32];
};
<p>void appendRecords(const string& filename, const vector<record>& data) {
ofstream file(filename, ios::binary | ios::in | ios::out);
if (!file.is_open()) {
// 文件不存在？创建新文件并写入
ofstream create(filename, ios::binary);
create.write(reinterpret_cast<const char>>(data.data()), data.size() sizeof(Record));
return;
}</const></record></p><pre class="brush:php;toolbar:false;">file.seekp(0, ios::end); // 定位到末尾
file.write(reinterpret_cast<const char>(data.data()), data.size() * sizeof(Record));</const>}
write() 的参数陷阱：别传结构体地址却写错 size
常见错误是把 &record 当成数组首地址，但写入长度仍用 sizeof(record)（单个结构体大小），结果只写了一个元素。或者误用 sizeof(arr)（在函数参数中退化为指针，结果恒为 8）。
- 对数组：若传入
Record arr[N]，需显式传入N，写入长度为N * sizeof(Record) - 对
vector<record></record>：用vec.data()+vec.size() * sizeof(Record) - 绝对不要对非 POD 结构体做
reinterpret_cast<char></char>—— 比如含std::string或std::vector成员的结构体，必须序列化，不能裸写内存
跨平台兼容性：结构体对齐必须显式控制
不同编译器、不同平台对结构体默认对齐策略不同（比如 Windows MSVC 默认 8 字节对齐，Linux GCC 可能按成员最大对齐数）。如果文件要在多平台间交换，必须统一打包方式：
- 用
#pragma pack(1)或alignas(1)强制 1 字节对齐（最安全，但性能略低） - 或用
[[gnu::packed]]（GCC/Clang）或__declspec(align(1))（MSVC） - 写入前检查
static_assert(is_standard_layout_v<record> && is_trivially_copyable_v<record>)</record></record>，避免后期踩坑
没做对齐控制的结构体，同一份代码在 x86_64 Linux 和 ARM64 macOS 上写出来的二进制很可能不兼容。
真正麻烦的从来不是怎么写进去，而是怎么保证下次读出来时每个字段都落在正确字节位置——对齐、POD 性、endianness（跨大小端设备时还得考虑）这三点漏掉任何一个，文件就废了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
