unsafe包是内存地址直通卡，需严格遵循类型转换、对齐、gc保活等规则，否则引发随机崩溃；unsafe.pointer不能解引用，必须转为具体类型指针；uintptr运算后须立即转回，禁止存储；切片转结构体须用&slice[0]；偏移必须用unsafe.offsetof获取。
unsafe 包不是指针操作工具包，而是内存地址直通卡——用错一步，GC 不管、对齐不保、越界无声、崩溃随机。
unsafe.Pointer 不能直接解引用，必须转成具体类型指针
很多人写 (*int)(p) 以为 p 是 unsafe.Pointer 就能直接解引用，其实编译器根本不让：它只允许你把 unsafe.Pointer 转成 *int、*byte 这类带类型的指针，再用 * 解引用。直接对 unsafe.Pointer 写 *p 会报错 invalid operation: *p (untyped nil) 或类似提示。
-
unsafe.Pointer本身是“无类型地址”，不能参与任何读写，只是个中转容器 - 必须走
(*T)(unsafe.Pointer(...))这条路径，且T的大小和对齐必须与目标内存实际布局匹配 - 比如从
[]byte首地址转*int64，若底层数组起始地址未按 8 字节对齐（如从buf[1]开始），运行时可能 panic：misaligned 64-bit atomic operation
uintptr 算术后必须立刻转回 unsafe.Pointer，不可存储或跨语句使用
把 unsafe.Pointer 转成 uintptr 后，GC 就彻底丢失对该内存的引用跟踪。哪怕只隔一行赋值、一个函数调用、甚至一次 goroutine 切换，原对象都可能被回收。
- 错误写法：
addr := uintptr(unsafe.Pointer(&x)); time.Sleep(1); *(*int)(unsafe.Pointer(addr)) = 42→x可能在 sleep 期间被 GC 回收 - 正确写法：
(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(u.field)))→ 所有计算在单表达式内完成，GC 仍能通过&x保活 - 若需跨函数传递偏移结果，必须传入原始 Go 指针（如
*T），并在接收端重新计算，不能传uintptr
切片转结构体或数组时，&slice[0] 是唯一安全起点
写 &slice 得到的是 slice header（含 len/cap/data 三字段）的地址，不是底层数组地址。把它当数组首地址用，等于往 header 上写数据，轻则覆盖 data 字段，重则触发 panic: invalid memory address or nil pointer dereference。
- 正确获取底层数组首地址：
unsafe.Pointer(&slice[0])，前提是len(slice) > 0 - 空切片没有
slice[0]，取地址会 panic；需先判断len > 0或用unsafe.Slice（Go 1.17+）替代手动转换 - 想把
[]byte当[4]byte用？别用(*[4]byte)(unsafe.Pointer(&b[0]))—— 数组类型要求长度精确匹配，越界访问不会报错但行为未定义
访问私有字段必须用 unsafe.Offsetof，手算偏移是定时炸弹
结构体字段偏移受字段顺序、类型大小、对齐填充共同影响。Go 编译器可能因版本、GOOS/GOARCH、-gcflags 优化级别微调布局。硬编码 offset = 8 看似能跑，上线后换机器或升级 Go 就崩。
- 必须用
unsafe.Offsetof(u.field)获取偏移，这是编译期确定的唯一可靠方式 - 字段是否导出不影响
Offsetof结果，但反射无法获取未导出字段地址（v.UnsafeAddr()会 panic） - 结构体含嵌套、指针、interface{} 等复杂字段时，偏移更易变；建议仅用于稳定 layout 的 POD 类型（如 C 兼容 struct）
最危险的不是写错代码，而是代码“看起来能跑”——越界读可能返回垃圾值，越界写可能破坏相邻字段或 header，GC 提前回收可能只在高负载时暴露。每行 unsafe 代码背后，都要能回答清楚：这块内存谁负责保活？地址是否对齐？偏移是否稳定？有没有更安全的替代方案（reflect、encoding/binary、接口断言）？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
