类大小与预期不一致本身不直接踩内存，但会因结构体布局错位导致memcpy等操作越界读写；根本原因是内存对齐、隐式vptr、虚基类及跨模块pack不一致引发填充差异，须用offsetof/alignof验证并static_assert校验。
类大小与预期不一致本身不会直接“踩内存”，但它往往是踩内存的深层诱因——因为结构体/类布局错位，导致 memcpy、reinterpret_cast、序列化、跨模块传递或 POD 类型强制对齐等操作越界读写。这类问题极难复现、调试器常显示“无异常”，但运行时偶发崩溃或数据错乱。
为什么 sizeof(MyClass) 比手算多/少 8 字节？
根本原因不是编译器“算错”，而是你忽略了内存对齐规则和隐式成员。C++ 标准要求每个成员按其自然对齐要求（如 double 是 8 字节对齐）存放，编译器会在成员之间或末尾插入填充字节（padding）。常见陷阱包括：
-
bool+int+double组合中，bool占 1 字节，但后面紧跟int（4 字节对齐）会导致 3 字节填充；double（8 字节对齐）前若偏移非 8 倍数，又会补更多 - 虚函数表指针（vptr）：只要类有虚函数或继承自虚基类，编译器就在对象开头悄悄加一个指针（通常 8 字节），你手算时完全没计入
- 虚基类子对象：涉及虚继承时，编译器可能额外插入虚基类偏移量字段，增大尺寸且布局不可预测
- 不同编译单元使用不同对齐选项（如
#pragma pack(1)仅在部分头文件生效），导致同一类在 A.cpp 和 B.cpp 中sizeof不同——这是最危险的场景，链接时不报错，运行时踩内存
用 offsetof 和 alignof 验证成员真实偏移
别靠眼睛数，用标准工具实测。例如检查 struct Packet 是否真按 4 字节对齐打包：
#include <cstddef>
#include <iostream>
<p>struct Packet {
uint8_t flag;
uint32_t id;
double timestamp;
};</p><p>int main() {
std::cout << "sizeof: " << sizeof(Packet) << "\n";
std::cout << "flag offset: " << offsetof(Packet, flag) << "\n";
std::cout << "id offset: " << offsetof(Packet, id) << "\n";
std::cout << "timestamp offset: " << offsetof(Packet, timestamp) << "\n";
std::cout << "alignof(double): " << alignof(double) << "\n";
}
输出若显示 timestamp offset 是 12 而非 5，就证实了中间有填充；若在某平台是 8，则说明 id 后被强制对齐到 8 字节边界——这直接影响你用 memcpy 解析网络包时是否越界。
立即学习“C++免费学习笔记（深入）”；
跨模块传递 POD 类时，static_assert 强制校验尺寸一致性
当类用于 IPC、共享内存或 DLL 导出时，必须确保所有使用方看到完全一致的布局。在头文件末尾加断言：
struct ConfigHeader {
uint32_t version;
uint32_t flags;
char reserved[16];
};
static_assert(sizeof(ConfigHeader) == 24, "ConfigHeader size mismatch - check padding and pack");
static_assert(offsetof(ConfigHeader, flags) == 4, "ConfigHeader flags offset broken");
这样一旦有人误加 #pragma pack(2) 或改成员类型，编译直接失败，而不是让程序在运行时随机崩掉。
排查踩内存时，先关掉优化再开 ASan
这类问题在 -O2 下极易被优化掩盖（比如编译器把越界读判定为未定义行为后整个删掉相关逻辑）。务必用以下方式编译：
- 关闭优化：
g++ -O0 -g -fsanitize=address或clang++ -O0 -g -fsanitize=address - 确保所有源文件、包括第三方静态库（需重新编译）都启用 ASan，否则 ASan 无法拦截跨模块的越界访问
- 运行时报出的
heap-buffer-overflow地址，结合offsetof输出反推是哪个字段越界——比如地址比obj->data起始小 3 字节，大概率是前一个字段对齐填充被误读
真正麻烦的是那些没触发 ASan 报警却改写了相邻字段值的情况，此时必须回到 offsetof + 内存 dump + 手动比对布局三者交叉验证——没有捷径，但每一步都能排除一类干扰。
