类大小与预期不一致本身不直接踩内存，但会因结构体布局错位导致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 </p>
<p>输出若显示 <code>timestamp offset</code> 是 12 而非 5，就证实了中间有填充；若在某平台是 8，则说明 <code>id</code> 后被强制对齐到 8 字节边界——这直接影响你用 <code>memcpy</code> 解析网络包时是否越界。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<h3>跨模块传递 POD 类时，<code>static_assert</code> 强制校验尺寸一致性</h3>
<p>当类用于 IPC、共享内存或 DLL 导出时，必须确保所有使用方看到完全一致的布局。在头文件末尾加断言：</p>
<pre class="brush:php;toolbar:false;">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 + 手动比对布局三者交叉验证——没有捷径，但每一步都能排除一类干扰。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
