反射能干的，unsafe不一定能直接替代：反射通过类型系统安全操作字段和方法，unsafe仅基于内存地址操作且无类型检查，二者适用场景与安全边界截然不同。
反射能干的，unsafe不一定能直接替代
反射是 Go 类型系统的“运行时镜像”，它通过 reflect.Type 和 reflect.Value 暴露结构体字段、方法、标签等信息，所有操作都在类型规则内进行——比如修改字段前会检查是否可寻址、是否导出、类型是否匹配。而 unsafe 不看这些，它只认内存地址和偏移量。你不能用 unsafe 直接“调用一个方法”或“解析 struct tag”，它连字段名都不知道。
- 想动态读写任意结构体字段？
reflect可以靠名字查；unsafe得先知道字段偏移（用unsafe.Offsetof或手动算），且字段布局一旦变化就崩 - 想把 JSON 字节流反序列化到未知结构体？必须用
reflect；unsafe连字节怎么映射到字段都得你手写 - 想绕过导出限制读私有字段？
reflect仍会 panic；unsafe能做到，但属于未定义行为，Go 运行时不保证后续兼容性
unsafe.Pointer 转换不是类型转换，而是内存重解释
unsafe.Pointer 是唯一能在不同指针类型间“中转”的类型，但它本身不携带类型信息。一次 *int64(*int32)(ptr) 强转，本质是告诉 CPU：“请把这块内存当成 int64 去读”，如果原始内存实际存的是 int32，结果就是高位补零或截断——没有类型检查，也没有自动转换逻辑。
- 常见错误：
*string(unsafe.Pointer(&x))对一个int变量取地址再强转，运行时不会报错，但解引用后得到的是乱码或崩溃 - 正确姿势：只在明确内存布局一致时才转，比如
[]byte和string底层结构相同，可用unsafe.String(unsafe.SliceData(b), len(b))（Go 1.20+）安全转换 - 切片扩容绕过
append？可以改cap字段，但需用自定义结构体对齐字段顺序，且len/cap字段偏移随 Go 版本可能微调，极不推荐生产使用
性能差距明显，但反射的开销常被高估
反射慢，是因为每次 Value.FieldByName 都要哈希查找字段、校验可访问性、构造新 Value；而 unsafe 写字段就是一条内存写指令。但在真实项目中，除非你在每毫秒执行上万次字段赋值，否则反射开销往往远小于 IO 或锁竞争。
- JSON 解析耗时 95% 在 UTF-8 解码和字节跳转，不是反射；ORM 映射瓶颈通常在数据库 round-trip，不是
SetInt - 真正该上
unsafe的场景极少：比如高频序列化库（如msgp）、底层网络包解析、或 runtime 内部实现 - 用
reflect+ 缓存Type和字段StructField位置，能消除大部分重复开销；盲目切到unsafe可能换来更难调试的 bug
panic 不等于 crash，但 unsafe 出错就是真 crash
reflect 的 panic（比如 Value.SetInt on unaddressable value）可被 recover 捕获，程序还能继续跑；而 unsafe 导致的非法内存访问（如空指针解引用、越界读写）触发的是 SIGSEGV，Go 运行时直接终止进程，连 defer 都不执行。
立即学习“go语言免费学习笔记（深入）”；
- 测试阶段用
go run -gcflags="-d=checkptr" *.go可捕获部分不安全指针用法（如跨 slice 边界读），但无法覆盖全部 - CGO 交互、系统调用、零拷贝网络栈等少数场景必须用
unsafe，此时务必严格限定作用域，封装成小函数并加充分注释说明风险 - 团队协作中，
unsafe代码应视为“需要两人 review + 单元测试覆盖边界条件”的高危区，而不是“性能优化捷径”
真正难的不是学会怎么用 unsafe，而是判断某段逻辑是否真的值得放弃类型安全——多数时候，问题出在设计，不在工具。
