在Go语言中，想要知道一个变量或者某种类型在内存里占了多少字节，通常有两个最直接的手段：使用标准库里的reflect包，或者使用更底层的unsafe包。这两种方式虽然都能拿到“大小”，但背后的机制、使用限制以及适用场景完全不同。理解它们的差异，对做内存优化、序列化协议设计以及对接C库都很有价值。
一、reflect包获取大小的方式
reflect是Go的反射库，它提供了一套在运行时检查类型和值的机制。通过reflect.TypeOf函数拿到类型信息后，可以调用它的Size方法，该方法会返回这个类型在内存中占用的字节数。这个值已经包含了编译器为了对齐而插入的填充字节，因此和真实分配的内存大小一致。
下面是一段典型的代码示例，展示如何用reflect获取多个类型的大小：
package main
import (
"fmt"
"reflect"
)
type User struct {
ID int32
Name string
Flag bool
}
func main() {
var u User
t := reflect.TypeOf(u)
fmt.Println("User size by reflect:", t.Size())
fmt.Println("int size:", reflect.TypeOf(0).Size())
fmt.Println("bool size:", reflect.TypeOf(true).Size())
fmt.Println("string size:", reflect.TypeOf("").Size())
}
从输出可以看到，User结构体里ID占4字节，Name是string（内部为指针加长度，通常16字节），Flag占1字节，但因为有内存对齐，整体大小往往会是24或32字节。reflect给出的就是最终对齐后的结果，这对估算对象在堆上的真实开销非常有用。
reflect方案的优点是完全安全，不依赖平台细节，代码可移植性好；缺点是需要在运行时通过反射拿到类型，有一定的性能开销，不适合在热路径里频繁调用。如果只是偶尔在初始化阶段打印一下类型尺寸，它是最省心的选择。
二、unsafe包获取大小的方式
unsafe是Go里一个特殊的标准包，它绕过了类型系统的安全检查。其中的Sizeof函数接收一个变量，并在编译期返回该变量对应类型的大小。和reflect一样，它返回的值也包含了对齐填充，但调用本身不会引入反射开销，编译器会直接把它替换成一个常量。
使用unsafe.Sizeof的代码看起来更轻量：
package main
import (
"fmt"
"unsafe"
)
type Point struct {
X int64
Y int64
}
func main() {
var p Point
// 编译期确定大小，无运行时反射开销
fmt.Println("Point size by unsafe:", unsafe.Sizeof(p))
var i int
fmt.Println("int size by unsafe:", unsafe.Sizeof(i))
}
unsafe.Sizeof的参数虽然写成变量形式，但实际上编译器只关心它的类型。比如传一个未初始化的零值变量也没问题，因为不会真的去读内存。由于是编译期常量，它可以用于数组长度定义、内存池块大小计算等对性能敏感的地方。
不过unsafe的代价是牺牲了安全性：一旦涉及指针运算或错误类型转换，很容易写出在跨平台时崩溃的代码。另外，unsafe包在Go版本升级时保证不如普通标准库稳定，虽然目前Sizeof语义一直没变，但官方文档明确提示使用者要自行承担风险。
三、reflect与unsafe的对比与选择
从结果准确性上看，两者返回的大小数值在大多数情况下是相同的，因为都遵循Go的内存对齐规则。但使用姿势和适用面不同，可以通过下面的表格快速区分：
| 维度 | reflect.Type.Size | unsafe.Sizeof |
|---|---|---|
| 获取时机 | 运行时 | 编译期 |
| 性能开销 | 有反射开销 | 几乎为零 |
| 安全性 | 类型安全 | 绕过检查 |
| 典型用途 | 调试、通用库 | 底层优化、内存布局 |
如果你在写一个通用的序列化框架，需要支持任意传入类型并知道其尺寸，reflect是更稳的做法；如果你在写一个高性能缓存，需要精确控制一个对象池里每个块的大小，unsafe会更直接。
需要特别注意的是，无论是reflect还是unsafe，它们给出的都是“这个类型本身”的大小。如果类型里包含指针（比如string、slice、map或指针字段），返回的数字并不包括指针指向的那块堆内存。例如一个slice头部只有24字节左右，但它背后的底层数组可能很大，这一点在估算总内存占用时经常被忽略。
四、常见误区与正确写法
一个常见的错误是以为unsafe.Sizeof能算出“动态数据”的总量。比如下面这段代码：
package main
import (
"fmt"
"unsafe"
)
func main() {
s := make([]int, 1000)
// 错误认知：以为会返回8000字节
fmt.Println(unsafe.Sizeof(s)) // 实际只打印slice头大小
}
上面打印出来的只是切片头（指向数组的指针、长度、容量）的大小，而不是背后那1000个int的空间。要拿到真实占用，必须自己乘以元素大小，或者对底层数组单独计算。
另一个误区是在泛型或接口类型上直接用unsafe.Sizeof，由于接口内部是双字结构（类型和数据指针），无论装了什么具体值，接口变量本身的大小是固定的，无法反映动态内容。这种时候如果真想知道“里面东西多大”，只能配合reflect把具体类型拆出来再算。
总结来说，获取变量或类型大小并不是复杂操作，但选错工具会导致性能浪费或估算偏差。在业务代码里优先用reflect图个省心，在底层库或性能敏感处用unsafe换取效率，同时始终记住它们只计算“类型自身”，不追踪指针目的地。