short在结构体中按2字节对齐，偏移从下一个2的倍数地址开始；前面成员结束于奇数offset时插入1字节填充，偶数则紧贴放置；结构体总大小向上对齐至最大成员对齐值（通常为2）。
short 在结构体里的对齐偏移怎么算
直接看结果：默认情况下，short 要求 2 字节对齐，但它在结构体里的实际偏移，取决于它前面所有成员的总大小和对齐需求。不是“只要前面凑够 2 字节就放”，而是“从下一个满足 2 字节对齐的地址开始放”。
常见错误现象：sizeof(struct { char a; short b; }) 是 4 而不是 3 —— 因为 b 不能紧挨着 a 放在 offset 1，必须从 offset 2 开始（因为 2 是 2 的倍数），所以编译器在 a 后面插了 1 字节填充。
- 如果前一个成员结束位置是奇数（比如 offset 1、3、5），
short就会插入 1 字节 padding 再放 - 如果前一个成员结束在偶数 offset（0、2、4…），
short直接紧贴放置 - 结构体整体大小也会向上对齐到其最大成员对齐值的整数倍（比如含
short但无更大类型，就对齐到 2）
__attribute__((packed)) 能否让 short 不对齐
能压，但代价明确：生成的代码可能触发未对齐访问（ARMv7 默认禁用，x86 通常容忍但慢），且某些平台（如 RISC-V 或严格模式下的 ARM）会直接抛 Bus error。
使用场景仅限于内存敏感且你完全控制读写路径的情况，比如解析网络包或 flash 固件格式；绝不要用于跨线程共享或频繁访问的结构体字段。
立即学习“C++免费学习笔记（深入）”；
-
struct __attribute__((packed)) S { char a; short b; };→sizeof(S)是 3，b地址是 offset 1 - 读写
b时，GCC 可能生成ldrh+uxth（ARM）或多条字节操作（RISC-V），性能下降明显 - Clang 在
-fsanitize=undefined下会对未对齐short访问报alignment-of错误
不同平台下 short 的对齐值真的一样吗
绝大多数主流平台（x86-64、ARM64、RISC-V64）上，short 的自然对齐都是 2 —— 这由 ABI 规定，不是编译器自由发挥。
但有两个关键例外：
- Windows x64 上，
short对齐仍是 2，但结构体整体对齐按最大成员取 min(16, max_align)，所以即使只有short，结构体也可能被对齐到 16（如果用了 SSE 类型或alignas(16)） - 某些嵌入式小端 DSP 或老款 PowerPC ABI 中，
short可能要求 1 字节对齐（即无对齐约束），但这是非标准扩展，需查具体target的 ABI 文档 - 用
_Alignof(short)编译期查最稳，别硬记；它返回的是该平台该编译器下的真实对齐值
想精确控制 short 位置，该用 alignas 还是 pragma pack
优先用 alignas 显式声明字段对齐，而不是 #pragma pack 全局降级——后者容易误伤其他字段，且不可嵌套、难维护。
alignas 只影响目标变量/字段本身起始地址，不影响前后填充逻辑；而 #pragma pack(n) 是修改整个翻译单元的默认对齐粒度，副作用大。
-
struct S { char a; alignas(2) short b; };和默认一样，没变；但alignas(1)强制b从任意地址开始（等效 packed 字段） -
alignas(4) short b;会让b从 4 的倍数地址开始，可能插入额外 padding，sizeof(S)变大 -
#pragma pack(1)后所有结构体都失去自然对齐，哪怕里面只有int也会被压成 4 字节不带 padding，风险远超单个short
真正难搞的从来不是 short 自身，而是它夹在 char 和 int 中间时，不同 ABI 对“结构体最大对齐值”的定义差异，以及你是否在跨平台序列化时混用了 pack 和非 pack 模式。
