sizeof(int)在Windows和Linux下通常均为4字节，由编译器实现决定而非操作系统；易混淆的是long：Windows为4字节，Linux x86_64为8字节。
sizeof(int) 在 Windows 和 Linux 下为什么不一样
它不一定不一样——int 的大小由编译器实现决定，不是操作系统直接规定的。主流 x86_64 平台下，GCC、Clang、MSVC 都把 int 定为 4 字节，和 Win/Linux 无关。真正容易混淆的是 long：在 Windows（MSVC 或 MinGW）上是 4 字节，而在 Linux（GCC）x86_64 下是 8 字节。
常见错误现象：printf("%ld", some_long_value) 在 Windows 上跑崩，或读出乱码——因为 %ld 期望 8 字节，但实际传入的是 4 字节的 long（MSVC）。
- 用
sizeof(long)实测，别靠记忆或文档猜 - 跨平台代码中，优先用
int32_t/int64_t替代int/long - Windows 上 MSVC 的 LLP64 模型（
long long是 8 字节，long是 4 字节），Linux 上 LP64 模型（long和pointer都是 8 字节）
char * 和 void * 的 sizeof 结果为什么总一样
因为它们都是指针类型，而指针大小只取决于地址空间宽度，和指向什么类型无关。在 64 位编译环境下，sizeof(char*)、sizeof(void*)、sizeof(int*) 全是 8；32 位下全是 4。
容易踩的坑：char buf[10]; sizeof(buf) 是 10，但 char *p = buf; sizeof(p) 是 8（或 4）——初学者常误以为“p 指向数组，所以大小还是 10”。
- 数组名在
sizeof中不退化为指针，但传参给函数后就退化了 void*不能直接算术运算（p++非法），但sizeof对它完全合法- 结构体里嵌套指针字段时，
sizeof只算指针本身，不算它指向的内容
结构体 sizeof 结果比成员字节和还大
这是内存对齐（alignment）导致的填充（padding）。编译器会在成员之间或末尾插入空白字节，让每个成员起始地址满足其对齐要求（通常是自身大小的整数倍）。
典型错误：用 memcpy 把结构体当二进制块发网络，对方平台结构体布局不同就解析错——尤其涉及 bool、char 和 int 混排时，填充位置可能不同。
- 用
_Pragma("pack(1)")或__attribute__((packed))强制紧凑布局，但会降低访问性能 - 检查对齐：用
_Alignof(type)（C11）或alignof（C++）看类型要求 - 结构体最后一个成员之后可能还有填充，所以
sizeof(struct foo)不一定等于各成员sizeof之和
float 和 double 的 sizeof 在所有平台都固定吗
sizeof(float) 几乎总是 4，sizeof(double) 几乎总是 8——这是 IEEE 754 单/双精度格式事实上的实现标准，GCC、Clang、MSVC 全部遵守。但严格来说，C 标准只要求 sizeof(float) <= sizeof(double) <= sizeof(long double)，没硬性规定字节数。
真正危险的是 long double：x86_64 Linux GCC 默认用 80 位扩展精度（sizeof(long double) == 16，含填充），而 MSVC 直接等价于 double（sizeof == 8）。
- 不用
long double做跨平台序列化或 ABI 兼容接口 - 浮点数比较别用
==，哪怕sizeof相同，二进制表示也可能因编译器优化路径不同而微异 FLT_EVAL_METHOD宏会影响中间计算精度，和sizeof无关，但会让相同代码在不同平台产生不同结果
对齐方式、指针模型、填充规则——这些才是 sizeof 差异背后真正要盯住的东西，而不是死记某个类型的字节数。
