type.size() 与 unsafe.sizeof() 结果一致，均包含对齐填充；区别在于 type.size() 作用于类型描述，unsafe.sizeof() 作用于值，二者均非字段原始大小之和。
为什么 Type.Size() 返回的值和 unsafe.Sizeof() 不一样
因为 Type.Size() 返回的是该类型在内存中「实际布局后」的总字节数（含对齐填充），而 unsafe.Sizeof() 作用于具体值，结果相同——但很多人误以为它算的是“字段原始大小之和”，其实不是。真正容易混淆的点在于：反射拿到的 Type 对象描述的是类型定义本身，不依赖实例，所以 Type.Size() 是可靠的类型级尺寸；但如果你用结构体字面量直接传给 unsafe.Sizeof()，也得到同样结果。
- 常见错误现象：
unsafe.Sizeof(struct{a int8; b int64})返回 16，但手动加int8(1) +int64(8) = 9，误以为反射出错了 - 根本原因：结构体字段间存在对齐填充，
Type.Size()和unsafe.Sizeof()都包含这部分 - 验证方式：用
fmt.Printf("%#v", unsafe.Offsetof(s.b))看b的偏移，就能发现中间有 7 字节填充
Type.Size() 在接口类型或指针类型上返回什么
它返回的是「该接口变量本身」或「该指针变量本身」占用的空间，不是底层值的大小。比如 *int 的 Type.Size() 是 8（64 位系统），和 *string 一样；interface{} 的 Type.Size() 也是 16（两个 word：type pointer + data pointer）。
- 使用场景：做序列化预分配缓冲区、估算 map/slice 元素内存开销时，必须分清是“容器变量大小”还是“元素内容大小”
- 参数差异：传入
reflect.TypeOf((*int)(nil)).Elem()得到int类型，.Size()是 8；而reflect.TypeOf((*int)(nil))是*int，.Size()是 8（指针大小） - 容易踩的坑：对
interface{}调用.Size()，得到的是 16，不代表里面int或[]byte的大小
数组、切片、字符串的 Type.Size() 含义完全不同
数组类型（如 [3]int64）的 Type.Size() 是固定总长：3 × 8 = 24；切片（[]int64）和字符串（string）都是头结构大小，即 24 字节（三个 word：ptr/len/cap 或 ptr/len）——它们不反映底层数组长度。
- 性能影响：用
Type.Size()估算[]byte占用内存会严重低估，因为它只算 slice header，不算 underlying array - 兼容性注意：32 位系统下这些 header 大小是 12 字节（ptr/len/cap 各 4 字节），
Type.Size()会自动适配 - 正确做法：要估算切片总内存，得用
cap(s) * reflect.TypeOf(s).Elem().Size()，再加 header 大小
嵌套结构体里字段顺序真的影响 Type.Size() 结果
是的，而且影响可能很大。字段排列决定填充位置，进而改变总大小。Go 不会重排字段顺序优化空间（不像 C/C++ 的某些编译器），所以你写的顺序就是内存布局顺序。
立即学习“go语言免费学习笔记（深入）”；
- 示例：
struct{a int8; b int64; c int8}→ Size=24；而struct{a int8; c int8; b int64}→ Size=16 - 为什么：前者在
a后需 7 字节对齐才能放b，c又落在b后，末尾再补 7 字节对齐；后者两个int8连着放，b紧跟其后，无额外尾部填充 - 容易被忽略的地方：JSON tag、ORM tag 不影响内存布局，但字段名首字母大小写（导出性）会影响反射可读性，和
Size()无关
