unsafe.pointer必须先转换为具体类型指针（如*int32）才能解引用，直接解引用或算术运算会编译失败；struct字段偏移和对齐由编译器决定，需用unsafe.offsetof等配合验证；slice底层操作易越界或悬垂；uintptr仅限单表达式内临时使用，不可跨作用域保存。
unsafe.Pointer 转换必须经过 *T 才能解引用
直接把 unsafe.Pointer 当指针用会编译失败——Go 不允许对 unsafe.Pointer 做算术或解引用。你得先转成具体类型的指针，比如 *int32 或 *struct{}，才能读写。
常见错误现象：invalid operation: cannot indirect p (variable of type unsafe.Pointer)
- 正确姿势：先
(*int32)(p)再*(*int32)(p) - 不能跳步：写成
**(*int32)(p)是错的，**语法不合法 - 如果原内存不保证对齐（比如从字节切片起始地址硬转
*int64），运行时可能 panic：”misaligned 64-bit atomic operation“
struct 字段偏移和对齐由 compiler 决定，不能手算
Go 的 struct 内存布局不是简单按字段顺序拼接。编译器会插入填充字节（padding）来满足每个字段的对齐要求，而对齐值取决于目标架构（如 amd64 上 int64 对齐到 8 字节，int32 到 4 字节）。
使用场景：想绕过反射快速访问 struct 字段、实现自定义序列化、或与 C 结构体交互。
- 别用
unsafe.Offsetof(s.field)猜字段位置，它返回的是相对于 struct 起始的偏移，但必须配合unsafe.Sizeof和unsafe.Alignof一起验证是否安全 - 字段顺序影响大小：把大字段放前面通常更省空间（减少 padding）
-
go tool compile -S可看实际布局，但不同 Go 版本可能微调，不能当契约依赖
slice 底层 Header 操作极易越界或悬垂
用 unsafe.Slice（Go 1.17+）或手动构造 reflect.SliceHeader 改 slice 长度/容量，是常见需求，但稍有不慎就踩内存坑。
常见错误现象：程序偶发 crash、读到脏数据、GC 提前回收底层数组。
- 手动改
reflect.SliceHeader时，Data字段必须指向已分配且未被 GC 回收的内存；指向局部变量地址（如&x）是致命错误 -
unsafe.Slice(ptr, len)更安全，但它不检查ptr是否有效，也不保证len在底层数组范围内 - 扩容后若原底层数组被 GC，新 slice 就成悬垂指针——除非你用
runtime.KeepAlive显式延长生命周期
uintptr 是整数，不是指针，不能长期保存
uintptr 常被用来暂存地址做计算（比如加偏移），但它不是 GC 友好的类型。一旦脱离当前表达式上下文，它就只是个数字，不会阻止对应内存被回收。
错误用法示例：把 uintptr 存进 map 或结构体字段，下一轮 GC 后再转回 unsafe.Pointer，大概率指向已释放内存。
- 只在单条表达式里用：如
(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(s.a))) - 绝不在函数返回值、全局变量、或跨 goroutine 传递中用
uintptr存地址 - 需要跨作用域持有时，必须用真正的指针类型（
*T）并确保对象生命周期可控
真正难的从来不是怎么写那几行 unsafe 代码，而是判断哪块内存此刻归谁管、对齐有没有被悄悄破坏、以及 GC 是否已经把它标记为可回收——这些没法靠编译器报错提醒，只能靠对 runtime 行为的持续验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
