Go禁止普通指针运算，因破坏类型安全与GC可靠性；仅unsafe.Pointer经uintptr中转可偏移；切片操作更安全高效，应优先使用。
Go 语言中，ptr + 1、p++、ptr1 - ptr2 这类指针运算**在普通指针上永远不合法，编译器会直接报错**——这不是 bug，也不是版本限制，而是 Go 类型系统主动拦截的硬性安全边界。
为什么 ptr + 1 编译失败？不是语法缺失，是设计拦截
当你写 var p *int; p = p + 1，Go 编译器会报：invalid operation: p + 1 (mismatched types *int and int)。这不是它“不会算”，而是拒绝把指针当整数参与运算。
- 普通指针
*T是带类型、受 GC 追踪的引用，它的值不能被当作地址数字随意加减 - 编译器不信任人工计算偏移：int 占 4 字节还是 8 字节？结构体字段对齐是否跨平台？这些都由运行时和编译器统一管理
- 一旦放开，GC 就无法判断
p + 3指向的对象是否还存活，可能提前回收或漏回收
unsafe.Pointer 是唯一入口，但必须经 uintptr 中转
真要按字节偏移（比如解析二进制协议、访问结构体字段），唯一合规路径是：&x → unsafe.Pointer → uintptr → unsafe.Pointer → *T。少任何一环，编译失败。
- 错误写法：
(*int)(unsafe.Pointer(&x) + 4)——unsafe.Pointer不支持+运算 - 危险写法：
u := uintptr(unsafe.Pointer(&x)); ...; (*int)(unsafe.Pointer(u + 4))——u是纯整数，中间若有函数调用（如fmt.Println），&x可能被 GC 回收 - 正确写法：
(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + 4))，所有转换在单表达式内完成
切片比指针运算更安全、也更快
99% 的遍历、取子段、随机访问需求，根本不需要指针偏移——[]byte 和 s[i] 就是为此设计的。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
s[i]在 debug 模式下自动做边界检查；release 模式下，现代 Go 编译器生成的汇编和 C 手动指针访问性能几乎一致 -
s[2:5]底层封装了起始地址 + 长度 + 容量，比(&s[0]) + 2更清晰、不可越界 - 想模拟“指针游标”？用
for i := range s或index += 1配合s[index]，语义明确且 GC 友好
unsafe.Slice 替代手写 reflect.SliceHeader（Go 1.17+）
以前有人用 reflect.SliceHeader 手拼切片头，极易崩溃；现在必须用 unsafe.Slice，它至少提供 debug 模式下的越界校验。
- 错误：
hdr := &reflect.SliceHeader{Data: uintptr(ptr) + offset, Len: n, Cap: n}——reflect.SliceHeader是非导出结构，布局不保证稳定 - 正确：
s := unsafe.Slice((*byte)(ptr), n)—— 第二个参数是长度，不是结束地址；ptr必须来自合法 slice/array 的首地址或其已知安全偏移（如unsafe.Offsetof） - 注意：
unsafe.Slice对nilslice、栈上局部变量地址、已释放内存的行为是未定义的，不校验也不提示
真正容易被忽略的不是“怎么写对”，而是“什么时候不该写”：只要标准库有 binary.Read、encoding/binary、bytes.Buffer 能解决的问题，就不要碰 unsafe.Pointer；每次使用都意味着你主动承担对齐、生命周期、GC 可见性三重校验责任。
