unsafe.Sizeof返回类型对齐后的内存尺寸，非字段简单相加，受字段顺序、对齐规则和填充影响；对引用类型仅返回头结构大小，不包含底层数据；结果为编译期常量，跨平台需注意指针/整数宽度差异。
unsafe.Sizeof 返回的是类型在内存中的对齐后尺寸
它不是简单把字段大小加起来，而是考虑了结构体字段的排列顺序、对齐规则和填充字节。比如 struct{a int8; b int64} 和 struct{b int64; a int8} 的 unsafe.Sizeof 结果很可能不同——前者通常为 16 字节（因 a 后要填充 7 字节对齐 b），后者是 16 或更小（取决于平台），但绝不是 9。
- 对齐单位由最大字段决定：
int64在大多数平台对齐到 8 字节 - 字段顺序影响填充量，这是优化结构体内存的关键切入点
-
unsafe.Sizeof对 slice、map、chan 等引用类型只返回头结构大小（如 slice 是 24 字节），不包含底层数组或哈希表数据
不能用 unsafe.Sizeof 计算运行时动态分配的内存总量
它只接受类型或值的表达式，在编译期就确定结果，无法反映堆上实际分配了多少字节。比如 make([]int, 1000) 的底层数组占用 8000 字节（假设 int 是 8 字节），但 unsafe.Sizeof 作用于该 slice 变量本身，只返回 slice header 大小（通常是 24 字节）。
- 错误写法：
unsafe.Sizeof(make([]int, 1000))→ 得到 24，不是 8000 - 正确估算 slice 底层数组：用
cap(s) * unsafe.Sizeof(s[0])（注意需确保s非空） - 字符串同理：
unsafe.Sizeof返回 16 字节（header），真实数据在只读段，长度需用len(s)
跨平台时要注意指针和整数宽度差异
unsafe.Sizeof((*int)(nil)) 在 64 位系统是 8，在 32 位系统是 4；unsafe.Sizeof(int(0)) 则依赖 int 的平台定义（可能是 4 或 8）。如果代码需要可移植，别硬编码预期值，尤其在做序列化或二进制协议解析时。
- 避免写
if unsafe.Sizeof(int(0)) == 8这类判断，改用strconv.IntSize或unsafe.Sizeof(int64(0))显式指定 - 结构体中混用
int和int64会导致不同平台对齐行为不一致，unsafe.Sizeof结果也会变 - 交叉编译测试时务必检查
unsafe.Sizeof输出，尤其是 Cgo 混合场景
和 reflect.TypeOf(t).Size() 的区别在哪
两者数值通常相等，但语义和使用约束不同：unsafe.Sizeof 是编译期常量（只要参数是类型或字面量），而 reflect.TypeOf(t).Size() 是运行时调用，开销略高且不能用于常量上下文（比如数组长度声明）。
立即学习“go语言免费学习笔记（深入）”；
-
[unsafe.Sizeof(struct{}{})]byte合法；[reflect.TypeOf(struct{}{}).Size()]byte编译失败 - 反射方式能处理接口值的具体类型，
unsafe.Sizeof对接口变量只返回 interface header 大小（16 字节） - 性能敏感路径优先用
unsafe.Sizeof，但注意它绕过类型安全检查，传错类型也不会报错，只是结果无意义
真正容易被忽略的是：unsafe.Sizeof 看不见字段 tag（比如 json:"-" ）、看不见嵌入字段是否被导出，也看不见编译器可能做的优化（如空结构体字段合并）。它只忠实地反映当前编译目标下，该类型在内存里的布局快照。
