go 语言出于内存安全与垃圾回收简化的设计考量，明确禁止指针算术（如 p++、p + 1 等），即使底层可通过 unsafe 包绕过限制，也强烈不推荐在生产代码中使用。
go 语言出于内存安全与垃圾回收简化的设计考量，明确禁止指针算术（如 p++、p + 1 等），即使底层可通过 unsafe 包绕过限制，也强烈不推荐在生产代码中使用。
在 C 或 C++ 中，开发者常借助指针算术遍历数组或内存块，例如 int* p = arr; for (int i = 0; i 语法上不合法——编译器会直接报错：invalid operation: p + 1 (mismatched types *int and int)。
这是 Go 的有意设计，而非语言缺陷。官方 FAQ 明确指出：禁用指针算术可从根本上杜绝非法地址访问（如越界解引用），同时使编译器优化和垃圾回收器实现更简单、更可靠。现代编译器（如 Go 的 SSA 后端）能将基于索引的循环（for i := range slice）优化为与指针遍历同等高效的机器码，因此性能并非妥协理由。
✅ 推荐做法：始终使用 Go 原生、安全的遍历方式：
vals := []int{10, 20, 30, 40}
// 方式1：索引遍历
for i := 0; i <p>⚠️ 警告：unsafe 不是“高级指针工具”，而是<strong>绕过类型系统与内存安全边界的逃生舱口</strong>。以下代码虽能运行，但属于反模式：</p><pre class="brush:php;toolbar:false;">import "unsafe"
vals := []int{10, 20, 30, 40}
start := unsafe.Pointer(&vals[0])
elemSize := unsafe.Sizeof(int(0))
for i := 0; i <p>该代码不仅丧失了 Go 的内存安全保障，还可能因 slice 底层内存重分配、GC 移动对象（对 reflect.SliceHeader 等场景）而引发未定义行为，且完全不可移植、不可维护。</p><p>? 总结： </p>
- Go 不支持任何形式的指针算术，这是语言安全基石之一；
- 所有数组/切片遍历应使用 for 索引或 range —— 它们足够高效且语义清晰；
- unsafe 包仅限极少数底层系统编程场景（如 sync/atomic、reflect 包内部实现），普通业务逻辑中绝不应出现；
- 若遇到“必须用指针算术”的需求，通常是设计信号：应重新审视数据结构（如改用 []byte + binary.Read 处理二进制协议）或算法逻辑。
