go中指针数组即[]t切片，需用make([]int,3)声明并显式初始化各元素，不可直接取切片元素地址以防悬垂指针；其内存开销通常大于值数组，仅在大结构体且需共享或部分修改时才有优势。
怎么声明和初始化一个指针数组
Go 里没有“指针数组”这种独立类型，它只是 []*T —— 一个元素类型为 *T 的切片。别被 C 风格术语带偏，Go 中数组长度固定且极少直接使用，实际几乎总是用切片。
常见错误是写成 *[]T（指向切片的指针），这和 []*T 完全不同：前者只存一个地址，后者存一堆指向 T 的地址。
-
ptrs := make([]*int, 3)创建长度为 3 的切片，每个元素初始为nil - 必须显式分配每个元素指向的值：
i := 42; ptrs[0] = &i - 若想让所有指针指向新分配的零值，可循环：
for i := range ptrs { ptrs[i] = new(int) }
为什么不能直接用 &arr[i] 初始化指针数组
对局部变量取地址没问题，但对切片元素（如 &slice[i]）取地址，在 slice 底层数组发生扩容时会导致悬垂指针 —— Go 运行时不会跟踪这些指针，它们仍指向旧内存块，读写会引发未定义行为或 panic。
典型报错虽不总出现，但 fatal error: unexpected signal during runtime execution 或静默数据错乱都可能发生。
立即学习“go语言免费学习笔记（深入）”；
- 避免：
s := []int{1,2,3}; ptrs := []*int{&s[0], &s[1]}—— s 后续 append 可能失效 - 安全做法：先确保底层数组不再变化，或改用显式分配的新变量：
x := s[0]; ptrs[0] = &x - 若需长期持有元素地址，考虑用 map 或结构体字段替代切片索引
指针数组在内存布局上比值数组省空间吗
不一定。[]*int 比 []int 多一层间接访问，且每个指针本身占 8 字节（64 位系统），还要额外分配每个 *int 指向的堆内存（至少 8 字节 + malloc header）。小类型（如 int、bool）用指针数组反而更耗内存、更慢。
只有当值类型较大（如 struct 超过 32 字节）、且你只频繁修改其中少数字段，或需要共享/别名语义时，[]*T 才有优势。
- 对比：1000 个
int值切片 ≈ 8KB；1000 个*int切片 ≈ 8KB（切片头）+ 8KB（指针存储）+ 1000×16B（每个 new(int) 开销）≈ 32KB+ - GC 压力更大：每个
*int是独立堆对象，GC 需单独追踪 - 缓存不友好：指针分散在堆上，CPU cache line 命中率远低于连续的
[]int
如何安全地将 []T 转换为 []*T
没有零成本转换。必须逐个取地址并确保目标生命周期足够长。最常用模式是复制值再取址，或使用辅助函数封装逻辑。
注意：不能用 unsafe 强转 —— Go 的 slice header 和指针数组内存布局完全不同，强转必然崩溃或越界。
- 推荐方式：
ptrs := make([]*T, len(src)); for i := range src { x := src[i]; ptrs[i] = &x } - 如果 src 是只读且生命周期可控（如全局变量或传入的不可变切片），可改用
ptrs[i] = &src[i]，但仍要确认 src 不会扩容 - 对大 struct，考虑用
for i := range src { ptrs[i] = &src[i] }并接受潜在风险，或重构为直接操作索引而非指针
真正难处理的不是语法，而是所有权和生命周期判断 —— 每个 *T 背后都藏着一个隐式堆分配决策，漏掉一个就可能埋下 GC 泄漏或并发竞争的坑。
