sizeof 返回编译期常量，与运行时内容无关；它计算对象布局大小，含对齐填充但不含虚表指针额外开销，不支持不完整类型，且在模板/auto中按推导类型计算。
sizeof 返回的是编译期常量，不是运行时大小
它在编译阶段就确定了值，和变量实际内容、内存布局无关。比如 sizeof(std::vector<int>)</int> 永远只返回指针+size+capacity 三个成员的总大小（通常是 24 或 16 字节），而不是它当前容纳了多少个 int。
- 对数组名用
sizeof得到的是整个数组字节数，但传进函数后退化为指针，sizeof就只剩指针大小（如 8） -
sizeof对引用类型返回的是被引用对象的大小，不是引用本身的大小（引用通常不占额外空间，但标准不保证） - 空类
struct {}的sizeof是 1 —— 这是为了让每个对象有唯一地址，别指望它是 0
char、bool、enum 的 sizeof 容易误判
sizeof(char) 固定为 1，这是 C++ 标准定义，和平台无关；但 sizeof(bool) 在不同编译器下可能是 1、4 甚至更多（MSVC 常为 1，GCC/Clang 默认 1，但加 -fshort-enums 可能影响枚举）。
-
enum默认底层类型由编译器决定：小范围枚举可能用int8_t，大范围强制升到int或long；显式指定如enum : uint16_t才能确保sizeof是 2 -
sizeof(wchar_t)在 Windows 是 2，在 Linux/macOS 通常是 4 —— 别硬记，用static_assert(sizeof(wchar_t) == 2)显式约束更安全 -
sizeof(std::byte)永远是 1，但它不是char，不能隐式转换
结构体 padding 导致 sizeof 结果“不合理”
结构体大小 ≠ 成员大小之和，因为编译器会按最大成员对齐（alignment），中间插填充字节。比如 struct { char a; int b; } 在大多数平台是 8 字节，不是 5。
- 用
alignas可以强制对齐，但可能增大sizeof；用#pragma pack(1)能去掉 padding，但会降低访问性能，且跨平台时需格外小心 -
sizeof不包含虚函数表指针（vptr）的“额外开销”——它算在类对象大小里了；带虚函数的空类sizeof是 8（64 位下），不是 1 - 继承链中，基类子对象可能被重排或共享 padding，
sizeof结果未必是各基类sizeof相加
模板和 auto 推导中 sizeof 的陷阱
对模板参数或 auto 变量用 sizeof，得到的是推导后的具体类型大小，不是“原始表达式”的大小。比如 auto x = arr[0]（arr 是 int[10]），x 是 int，sizeof(x) 是 4，不是 sizeof(arr) 的 40。
立即学习“C++免费学习笔记（深入）”；
- 函数参数写成
void f(T&)，sizeof(T)是引用所绑定类型的大小，不是引用类型本身 -
sizeof无法用于不完整类型（如前置声明的类），否则编译报错：error: 'sizeof' applied to an incomplete type - 用
sizeof...(Args)获取可变参数包长度，这是特例，不是常规sizeof行为
真正麻烦的从来不是 sizeof 本身，而是它看起来像函数、用起来像运行时操作，却死死卡在编译期；一旦混进宏、模板偏特化或 ABI 敏感场景，一个没注意对齐或没看准类型推导，后面内存踩踏或序列化错位就很难排查。
