Go数组指针修改元素技巧

Go语言中，数组指针（*[N]T）是唯一能原地修改固定大小数组内容的机制，其核心在于必须传递指向整个数组的指针而非单个元素地址，解引用时需用(*p)[i] = val且括号不可省略；它与指针数组([N]*T)有本质区别，前者内存连续、类型严格、零值安全，后者存储分散指针、易因nil引发panic；尽管功能精准，但因类型不兼容、长度固化、易出错（nil解引用、越界访问），日常开发中应优先使用更灵活安全的slice，仅在栈空间敏感、避免逃逸或CGO对接C函数等特定场景才选用数组指针——理解这层取舍，才能避开Go底层操作中最隐蔽的硬伤。

怎么用指针改数组里的某个元素

Go 里数组是值类型，传参或赋值时会复制整个底层数组。想原地修改，必须传数组的指针——不是元素指针，而是指向整个数组的指针。

常见错误是误以为 &arr[i] 就能改整个数组内容，其实它只拿到单个元素地址，对数组长度、其他元素无影响；真正要的是 *[N]T 类型的指针。

• 声明数组指针：用 var p *[3]int 或直接 p := &arr（arr 是 [3]int）
• 解引用后修改：写成 (*p)[1] = 42，不能省略括号，否则 *p[1] 会被解析为 *(p[1])（非法）
• 函数中接收数组指针：func update(p *[5]string) { (*p)[0] = "hello" }，调用时传 &myArr

数组指针和指针数组别搞混了

*[N]T 是“指向 N 个 T 的数组的指针”，而 [N]*T 是“存放 N 个 *T 的数组”，二者内存布局、用途、零值行为完全不同。

典型误用场景：想批量修改字符串，却定义成 arr := [3]*string，结果每个元素都是 nil 指针，*arr[0] panic；其实你可能只需要一个 *[3]string 来统一控制底层数组。

• *[3]int：底层连续 3 个 int，指针指向起始地址，len/cap 不适用，但可直接索引
• [3]*int：底层是 3 个指针值，每个可能指向不同地方，甚至为 nil
• 打印 fmt.Printf("%p", p) 可验证：前者输出数组首地址，后者输出指针数组自身地址

为什么 slice 更常用，而不是数组指针

因为数组大小是类型的一部分，[3]int 和 [4]int 是不同类型，无法通用；而 []int 是运行时长度可变的头结构，底层共享同一块内存，传参开销小且灵活。

除非明确需要栈上固定大小、避免逃逸、或对接 C 函数（如 CGO 中要求 *[N]T），否则优先用 slice + &slice[0] 获取首元素地址（注意非空判断）。

• 传 slice 给 C 函数时，常配合 C.CBytes 或 unsafe.Slice（Go 1.21+）构造临时数组视图
• 用 unsafe.Pointer(&arr[0]) 获取数组首地址时，arr 必须是变量（不能是字面量或临时值），否则地址无效
• 数组指针在反射中类型是 *[N]T，用 reflect.ValueOf(p).Elem() 才能得到可遍历的数组值

修改时 panic 的几个关键原因

最常卡在 nil 指针解引用或越界访问，尤其在函数参数未校验、或误把 slice 当数组指针传入时。

比如函数签名是 func f(p *[5]int)，却传了 &[]int{1,2,3} —— 这根本编译不过；或者传了 nil 指针，(*p)[0] 直接 panic。

• 检查指针是否为 nil：if p == nil { return }，别依赖 defer recover
• 数组指针的长度不可变，(*p)[10] 即使 p 指向 [5]int 也会 panic，不靠编译器报错
• CGO 场景下，C 函数修改了内存，Go 端用 *p 读取前确保 C 已写完，且没触发 GC 移动（需 runtime.KeepAlive）

数组指针的“固定长度”既是约束也是保障，用错类型或忽略 nil/越界检查，比 slice 容易出硬伤。实际写业务逻辑时，90% 的情况该用 slice；只有当你真正在意那几个字节的栈空间、或必须匹配 C ABI，才伸手去碰 *[N]T。

今天关于《Go数组指针修改元素技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！