在C++开发中，直接把结构体写入二进制文件是最直观的持久化方式，但很多人在读取时却发现数据错位、字段值莫名其妙。这背后其实是内存对齐在起作用。编译器为了提高访问效率，会在结构体成员之间插入空白字节，导致对象在内存中的实际尺寸大于各成员尺寸之和。
一、内存对齐的基本原理
现代CPU访问内存时，通常要求数据的地址是其类型大小的整数倍。例如，一个4字节的int最好放在地址能被4整除的位置。如果结构体中的成员顺序不当，编译器就会在前面或中间插入填充字节，也就是padding，以满足对齐要求。
我们可以用一段简单代码观察这种现象。下面这个结构体在多数64位平台上，sizeof的结果往往是16而不是直观的8加1加4。
#include <iostream>
struct Record {
char flag; // 1字节
int id; // 4字节，前面会补3字节
double value; // 8字节，前面可能补4字节
};
int main() {
std::cout << sizeof(Record) << std::endl; // 通常输出16或24
return 0;
}
上面的代码中，char之后并不会紧挨着int，编译器会在flag后面填充3个字节，让id从4的倍数地址开始。不同平台、不同编译选项下对齐规则会有差异，这也是直接写二进制文件容易出问题的核心原因。
二、直接写结构体带来的文件问题
当我们使用ofstream的write方法，把结构体对象按sizeof大小整块写进文件，文件中就包含了那些填充字节。换一台对齐规则不同的机器读取，或者后期调整了结构体成员顺序，旧文件就无法正确解析。
以下写法在单机临时存储时看似方便，却埋下了兼容性隐患。一旦程序升级改了结构体，历史文件可能直接损坏。
#include <fstream>
struct Record {
char flag;
int id;
double value;
};
void save(const Record& r, const char* path) {
std::ofstream out(path, std::ios::binary);
out.write(reinterpret_cast<const char*>(&r), sizeof(Record));
}
void load(Record& r, const char* path) {
std::ifstream in(path, std::ios::binary);
in.read(reinterpret_cast<char*>(&r), sizeof(Record));
}
这种方法的优点是代码极短、写入速度快；缺点也同样明显：文件格式依赖内存布局，不具备可移植性，且浪费了填充字节所占的磁盘空间。
三、使用编译指令控制对齐
如果确实想保持结构体整体写入的简洁性，可以通过编译指令强制取消或改变对齐方式。在MSVC下用#pragma pack，在GCC或Clang下用__attribute__((packed))。
下面的例子让结构体按1字节对齐，此时成员紧密排列，sizeof等于各成员之和，写文件就不会有多余填充。但要注意，未对齐访问在某些硬件上会降低性能甚至引发总线错误。
#include <iostream>
#pragma pack(push, 1)
struct PackedRecord {
char flag;
int id;
double value;
};
#pragma pack(pop)
int main() {
std::cout << sizeof(PackedRecord) << std::endl; // 输出13
return 0;
}
使用pack(1)后，结构体大小变为13，文件内容紧凑。不过它牺牲了访问效率，且如果结构体被其他模块按默认对齐使用，就容易出现歧义。因此只建议在明确的文件格式层使用，不要用于通用业务对象。
四、手动序列化避免对齐依赖
更稳妥的做法是把每个字段单独写入，也就是手写序列化逻辑。这样文件格式完全由代码决定，与内存布局无关，也能轻松跨平台。
下面演示一种基础的字段级写入方式，先写定长类型再写字符串长度与内容。读取时按相同顺序解析即可，不怕编译器插针。
#include <fstream>
#include <string>
void writeRecord(std::ofstream& out, char flag, int id, double value, const std::string& name) {
out.write(&flag, sizeof(flag));
out.write(reinterpret_cast<const char*>(&id), sizeof(id));
out.write(reinterpret_cast<const char*>(&value), sizeof(value));
int len = static_cast<int>(name.size());
out.write(reinterpret_cast<const char*>(&len), sizeof(len));
out.write(name.data(), len);
}
void readRecord(std::ifstream& in, char& flag, int& id, double& value, std::string& name) {
in.read(&flag, sizeof(flag));
in.read(reinterpret_cast<char*>(&id), sizeof(id));
in.read(reinterpret_cast<char*>(&value), sizeof(value));
int len = 0;
in.read(reinterpret_cast<char*>(&len), sizeof(len));
name.resize(len);
in.read(&name[0], len);
}
这种方案的代价是代码量变大，且要小心字节序问题。对于跨语言、跨机器的文件，还应统一转为大端或小端，比如用htons、ntohl类函数处理多字节整数。
五、方案对比与选择建议
三种方式各有适用面。直接写结构体适合进程内临时缓存；pack压缩适合固定格式且追求简单的本地工具；手动序列化适合需要长期保存、跨平台分发的文件。
| 方式 | 兼容性 | 性能 | 代码复杂度 |
|---|---|---|---|
| 直接写结构体 | 差 | 高 | 低 |
| pragma pack | 中 | 中 | 低 |
| 手动序列化 | 好 | 中 | 高 |
实际项目中，若文件只在本机本程序使用，直接写结构体并锁定编译环境也可行；若涉及数据交换，务必采用明确字段边界的序列化。理解对齐不是为了杜绝它，而是让它在可控范围内发挥作用。
六、小结
内存对齐是C++对象布局的隐藏规则，写二进制文件时忽略它就会得到带填充的文件格式。通过认识padding来源、使用pack约束或彻底脱离内存布局做序列化，我们能让文件既紧凑又可靠。
建议在团队内统一文件读写规范，把结构体定义和序列化函数放在独立模块，避免业务代码里散落reinterpret_cast式的强转写入，从工程层面规避对齐陷阱。