go禁止p+1等指针算术是设计选择，为防越界、gc失控和未定义行为；唯一绕过方式是unsafe.pointer与uintptr组合，且须手动担责。
Go 为什么不能直接 p + 1 做指针偏移
因为 Go 编译器明确禁止传统指针算术——p + 1、p++ 这类写法在语法层面就报错。这不是限制，而是设计选择：避免越界访问、防止 GC 无法追踪对象、杜绝未定义行为。你写的不是“少了个功能”，而是被主动拦下了危险路径。
真正能绕过这层限制的，只有 unsafe.Pointer 和 uintptr 的组合，且必须手动承担全部安全责任。
- 编译期直接拒绝
*int + 1类表达式，不给机会运行 -
unsafe.Pointer是唯一能在*T和通用地址间转换的桥梁 -
uintptr是整数，加减合法，但一旦脱离unsafe.Pointer上下文，就失去类型和生命周期保证
用 unsafe.Offsetof 替代手算字段偏移
想从结构体首地址跳到某个字段？别猜 8 或 16 字节——结构体填充（padding）会让实际偏移和字段大小之和不一致，尤其跨平台或升级 Go 版本后可能突然崩。
正确做法永远是让编译器告诉你：
type Header struct {
Magic uint32
_ [4]byte // padding
Len uint64
}
h := &Header{Magic: 0xdeadbeef, Len: 1024}
base := uintptr(unsafe.Pointer(h))
lenOff := unsafe.Offsetof(h.Len) // 自动算出 Len 相对于 h 的真实偏移，比如 12
lenPtr := (*uint64)(unsafe.Pointer(base + lenOff))
-
unsafe.Offsetof(h.Len)返回的是字段起始地址相对于结构体首地址的字节数，不是类型大小 - 嵌套字段如
s.Inner.Field，必须逐层调用Offsetof，不能一跳到底 - 对齐要求必须满足：
base + lenOff必须是uint64要求的 8 字节对齐地址，否则 ARM 等平台会 panic
uintptr 加偏移后立刻转回指针并使用
这是最容易被忽略的时序陷阱：你把 uintptr 存起来、传出去、延迟解引用，等于把裸地址交给 GC 管理之外的世界。GC 不认识 uintptr，它只认 unsafe.Pointer；一旦原对象被回收，这个 uintptr 就变成悬空地址。
安全模式只有一种：算完立刻转、立刻用、立刻丢弃。
- 错误写法：
addr := base + offset; ...; ptr := (*int)(unsafe.Pointer(addr))—— 中间间隔了任意代码，风险不可控 - 正确写法：
(*int)(unsafe.Pointer(base + offset)) = 42—— 表达式内完成转换+解引用，无中间变量 - 若需多次访问同一偏移位置，应重新计算
base + offset，而不是复用旧uintptr
数组遍历中用 uintptr 模拟指针步进的边界雷区
想用 uintptr 遍历 [N]int 或 []byte 底层数组？可以，但必须卡死在分配单元内。
常见崩溃来源：
- 对
slice使用&s[0]获取首地址后，偏移超过cap(s) * size—— 越界读写，运行时不报错但行为未定义 - 对局部数组（如
var arr [10]int）取地址后逃逸失败，函数返回后栈帧销毁，后续uintptr解引用直接 panic - 用
unsafe.Slice（Go 1.20+）替代手算更安全，但它仍要求原始指针有效且长度不超底层数组容量
真正安全的起点，永远是堆上长期存活的对象、全局变量，或者明确用 runtime.KeepAlive 延长局部变量生命周期——但后者极难精确控制，慎用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
