反射是运行时类型镜像，unsafe是绕过类型的内存扳手：前者通过reflect.Type/Value读取元数据，安全但慢；后者用unsafe.Pointer直接操作内存地址，快但危险易崩溃。
反射是运行时的类型镜像，unsafe 是绕过类型的内存扳手
反射（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*解引用 - 反射可跨平台、受 GC 保护；
unsafe代码可能因 GC 优化（如栈对象逃逸分析变化）或内存对齐调整而突然失效 - 反射能处理接口、方法调用、字段遍历等高级操作；
unsafe连“字段名”都没有，只有“从起始地址跳 24 字节”这种硬编码逻辑
什么时候该用 reflect，而不是 unsafe？
绝大多数动态场景，反射就够了：JSON 编解码、配置绑定、测试断言（reflect.DeepEqual）、简单 ORM 字段映射。只要不卡在性能关键路径上，别碰 unsafe。
- 需要支持任意用户自定义结构体 → 用
reflect，unsafe要求你提前知道内存布局，无法泛化 - 要修改私有字段（比如单元测试中 patch 某个未导出字段）→ 反射可以
FieldByName+Set（需导出字段或用unsafe强行访问，但后者极不推荐） - 做 deep equal 比较 → 优先用
reflect.DeepEqual，除非明确知道数据不含func/map/unsafe.Pointer且性能压测证实它是瓶颈
unsafe 的典型误用：以为能“高效改 slice cap”
很多人想绕过 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。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：老实用
make([]int, len(s), newCap)+copy - 真要极致性能（如零拷贝网络包解析），应封装成独立模块，并用
//go:systemstack或//go:nosplit注释标明风险，且必须配套内存 layout 单元测试 - 所有
unsafe操作必须配go vet检查 + 显式注释说明“此处绕过类型安全，仅限 XXX 场景”
uintptr 和 unsafe.Pointer 的关键区别别搞混
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 快，但快得危险——这个权衡点，永远在代码审查时才真正浮现。 
