反射是运行时类型镜像,unsafe是绕过类型的内存扳手:前者通过reflect.Type/Value读取元数据,安全但慢;后者用unsafe.Pointer直接操作内存地址,快但危险易崩溃。
反射(reflect 包)让你在程序运行时“看见”变量的类型和值——它不改内存布局,只是读取 Go 运行时维护的类型元数据(reflect.Type 和 reflect.Value)。而 unsafe 包根本不关心类型,它只认内存地址:unsafe.Pointer 是类型转换的万能桥接器,unsafe.Sizeof、unsafe.Offsetof 直接操作结构体字段在内存中的字节偏移。前者安全但慢,后者快得像 C,但一错就 panic 或静默损坏数据。
reflect.ValueOf(x).Interface() 会做类型检查,失败则 panic;unsafe 做 (*int)(unsafe.Pointer(&x)) 时,编译器完全不管 x 是不是 int,只管把地址当 int* 解引用unsafe 代码可能因 GC 优化(如栈对象逃逸分析变化)或内存对齐调整而突然失效unsafe 连“字段名”都没有,只有“从起始地址跳 24 字节”这种硬编码逻辑绝大多数动态场景,反射就够了:JSON 编解码、配置绑定、测试断言(reflect.DeepEqual)、简单 ORM 字段映射。只要不卡在性能关键路径上,别碰 unsafe。
reflect,unsafe 要求你提前知道内存布局,无法泛化FieldByName + Set(需导出字段或用 unsafe 强行访问,但后者极不推荐)reflect.DeepEqual,除非明确知道数据不含 func/map/unsafe.Pointer 且性能压测证实它是瓶颈很多人想绕过 append 手动扩容 slice,写类似这样的代码:
func unsafeGrow(s []int, newCap int) []int {
hdr := (*reflect.SliceHeader)(unsafe.Pointer(&s))
hdr.Cap = newCap
return s
}
这在 Go 1.17+ 已被禁止:Go 运行时不再保证 []T 的底层结构是 SliceHeader,且该操作破坏了 slice 的内存安全契约。实际结果是:可能暂时工作,但会在某次 GC 或编译器更新后崩溃,或触发 fatal error: corrupt heap。
make([]int, len(s), newCap) + copy
//go:systemstack 或 //go:nosplit 注释标明风险,且必须配套内存 layout 单元测试unsafe 操作必须配 go vet 检查 + 显式注释说明“此处绕过类型安全,仅限 XXX 场景”unsafe.Pointer 是指针类型,GC

uintptr 是纯整数,存的是地址数值,GC 完全忽略它——一旦你把 unsafe.Pointer 转成 uintptr,又没立刻转回 unsafe.Pointer,中间那轮 GC 就可能回收掉原对象。
u := uintptr(unsafe.Pointer(&x)); ... time.Sleep(1); ptr := (*int)(unsafe.Pointer(u)) → x 可能在 sleep 期间被回收(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(s.a)))
unsafe.Pointer 是“活指针”,uintptr 是“死地址”;只要中间插入任何函数调用、goroutine 切换或 GC 点,uintptr 就不可信unsafe 代码,而是证明它在所有 GC 模式、所有内存对齐规则、所有 future Go 版本下都仍然安全。反射慢,但慢得确定;unsafe 快,但快得危险——这个权衡点,永远在代码审查时才真正浮现。