其思想是，出于速度和缓存的考虑，操作数应从与其自然大小对齐的地址中读取。为了实现这一点，编译器填充结构成员，以便对齐以下成员或以下结构。

struct pixel {
    unsigned char red;   // 0
    unsigned char green; // 1
    unsigned int alpha;  // 4 (gotta skip to an aligned offset)
    unsigned char blue;  // 8 (then skip 9 10 11)
};

// next offset: 12

x86体系结构始终能够获取未对齐的地址。然而，它速度较慢，当未对齐与两个不同的缓存线重叠时，当对齐的访问只会逐出一个缓存线时，它会逐出两个缓存线。

有些架构实际上必须捕获未对齐的读写，而早期版本的ARM架构（演变成当今所有移动CPU的架构）。。。事实上，他们只是返回了这些错误的数据。（他们忽略了低位。）

最后，请注意缓存线可以任意大，编译器不会试图猜测这些缓存线，也不会做出空间与速度的权衡。相反，对齐决策是ABI的一部分，表示最终将均匀填充缓存行的最小对齐。

TL；DR：对齐很重要。

除了其他答案，结构可以（但通常不）具有虚拟函数，在这种情况下，结构的大小还将包括vtbl的空间。

例如，如果您希望结构具有GCC的特定大小，请使用__attribute__（（打包））。

在Windows上，使用带有/Zp选项的cl.exe编译器时，可以将对齐设置为一个字节。

通常，CPU更容易访问4（或8）的倍数的数据，这取决于平台和编译器。

所以这基本上是一个对齐问题。

你需要有充分的理由来改变它。

其思想是，出于速度和缓存的考虑，操作数应从与其自然大小对齐的地址中读取。为了实现这一点，编译器填充结构成员，以便对齐以下成员或以下结构。

struct pixel {
    unsigned char red;   // 0
    unsigned char green; // 1
    unsigned int alpha;  // 4 (gotta skip to an aligned offset)
    unsigned char blue;  // 8 (then skip 9 10 11)
};

// next offset: 12

x86体系结构始终能够获取未对齐的地址。然而，它速度较慢，当未对齐与两个不同的缓存线重叠时，当对齐的访问只会逐出一个缓存线时，它会逐出两个缓存线。

有些架构实际上必须捕获未对齐的读写，而早期版本的ARM架构（演变成当今所有移动CPU的架构）。。。事实上，他们只是返回了这些错误的数据。（他们忽略了低位。）

最后，请注意缓存线可以任意大，编译器不会试图猜测这些缓存线，也不会做出空间与速度的权衡。相反，对齐决策是ABI的一部分，表示最终将均匀填充缓存行的最小对齐。

TL；DR：对齐很重要。

上面给出了很多信息（解释）。

我只想分享一些方法来解决这个问题。

您可以通过添加pragma pack来避免它

#pragma pack(push, 1)

// your structure

#pragma pack(pop) 

另请参见：

对于Microsoft Visual C:

http://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs.80%29.aspx

GCC声称与微软编译器兼容

https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Structure_002dPacking-Pragmas.html

除了前面的答案，请注意，无论包装如何，C++中没有成员订单保证。编译器可以（当然也可以）向结构中添加虚拟表指针和基结构的成员。即使是虚拟表的存在也没有得到标准的保证（没有规定虚拟机制的实现），因此可以得出这样的保证是不可能的。

我很确定C语言保证了成员顺序，但在编写跨平台或跨编译器程序时，我不会指望它。