Size() 返回的是类型对齐后的静态内存布局大小，不包含堆内存、不反映序列化体积、不保证C兼容，仅适用于栈内存和结构体内存密度分析。
reflect.Type.Size() 返回的真是对象占用的内存大小吗
不是，Size() 返回的是该类型在内存中「对齐后」所占字节数，不是字段原始大小之和，更不包含运行时动态分配的堆内存（比如 []byte 底层数组、string 数据指针指向的内容）。它只描述栈上或结构体内部的静态布局尺寸。
- 对结构体而言，
Size()包含字段间因对齐（alignment）插入的 padding 字节 - 对指针、接口、切片等头信息类型，
Size()只返回其自身头部大小（如unsafe.Sizeof(interface{})在 64 位系统是 16 字节），不包括底层数据 -
Size()和unsafe.Sizeof()在绝大多数情况下结果一致，但后者只能用于具体值或类型字面量，前者可用于运行时未知类型的reflect.Type
为什么 struct 的 Size() 比字段 sum 大很多
因为 Go 编译器按字段声明顺序和各自对齐要求插入 padding，确保每个字段地址满足其对齐约束。例如 int64 要求 8 字节对齐，若前面是 byte，就会空出 7 字节。
- 字段顺序直接影响
Size()：把大对齐字段放前面通常更紧凑；反过来可能膨胀明显 - 用
go tool compile -S或unsafe.Offsetof()可验证各字段偏移，算出 padding 分布 - 别依赖
Size()推断字段布局——反射无法暴露 padding 位置，只能靠Field(i).Offset逐个查
type BadOrder struct {
A byte // offset 0
B int64 // offset 8 → padding 7 bytes inserted
}
// Size() == 16
reflect.Type.Size() 在序列化或跨进程传递时能当“真实体积”用吗
不能。它只反映 Go 运行时内部表示的大小，和网络协议、磁盘存储、cgo 交互所需的二进制格式完全无关。
- JSON/Protobuf 等序列化后体积取决于字段名、编码规则、是否省略零值，和
Size()毫无关系 - cgo 传结构体给 C 时，需用
//export+#[repr(C)]风格布局，Go 默认结构体不保证 C 兼容，Size()值可能与 Csizeof不同 - GC 扫描、内存统计（如
runtime.ReadMemStats）也不基于Size()，而是跟踪实际分配的堆块
什么时候该信 Size()，什么时候必须绕开它
只在分析栈帧开销、估算结构体内存密度、或调试 GC 标记行为时，Size() 才有参考价值；只要涉及外部边界（IO、FFI、持久化），就得回归具体协议或手动计算。
立即学习“go语言免费学习笔记（深入）”；
- 想压内存？优先重排 struct 字段 + 用
unsafe.Sizeof验证，别只看reflect.Type.Size() - 做 RPC 序列化？直接测 payload 字节数，
Size()对压缩率、base64 开销等毫无意义 - 和 C 交换数据？用
unsafe.Offsetof+unsafe.Alignof逐字段校验，或改用encoding/binary显式编排
对齐规则和 padding 是编译期决定的，反射看到的只是结果——而人容易把它当成定义。
