[]*T 比 []T 占更多内存，因为前者存储 n 个 8 字节指针并需 n 次堆分配，产生额外 GC 压力；后者连续存放 T 值，一次分配完成。
![golang中[]*t与[]t的内存占用对比_指针数组与值数组](https://img.php.cn/upload/article/000/969/633/177119336157603.jpeg)
为什么 []*T 比 []T 占更多内存？
因为每个 *T 是一个指针（8 字节 on amd64），而 T 是值本身——如果 T 很小（比如 int、bool），那 []*T 光指针就比原值数组还大；更关键的是，[]*T 的元素分散在堆上，额外产生分配开销和 GC 压力。
常见错误现象：make([]*string, n) 后直接取 arr[i] 解引用，panic: nil pointer dereference——因为只分配了指针空间，没初始化指向的 string 实例。
-
[]T：底层数组连续存放T值，一次分配搞定 -
[]*T：底层数组存n个指针，但每个*T需单独new(T)或显式赋值才有效 - 若
T是大结构体（比如 1KB），[]T复制/传递成本高，这时[]*T反而更省（传指针快，且避免栈溢出）
append 时 []*T 和 []T 的行为差异
两者都支持 append，但语义不同：append([]T{}, t) 复制 t 的值；append([]*T{}, &t) 存的是 t 的地址——如果 t 是循环变量，所有指针可能最终指向同一个内存位置。
使用场景：批量处理结构体并需后续修改原数据时用 []*T；仅读取或做计算用 []T 更安全。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
for _, v := range data { arr = append(arr, &v) }→ 所有&v指向同一个栈变量 - 正确写法：
for i := range data { arr = append(arr, &data[i]) }或for _, v := range data { v := v; arr = append(arr, &v) } -
append([]T{}, t)不影响原t；append([]*T{}, &t)后通过指针能改到t
GC 和逃逸分析怎么看哪个更重？
运行时不会“统计总内存”，但逃逸分析能告诉你什么被分配到堆上。[]T 中的 T 若不逃逸，整个切片可能全在栈上；而 []*T 的每个 *T 几乎必逃逸（除非 T 极小且编译器做特殊优化）。
验证方式：加 -gcflags="-m" 编译，看输出里有没有 moved to heap。例如 make([]*int, 10) 会提示“&tmp escapes to heap”。
-
[]int（长度 1000）→ 约 8KB 栈空间（若未逃逸） -
[]*int（长度 1000）→ 底层数组 8KB + 1000 次堆分配（每次 8B + malloc header），GC 跟踪 1000 个对象 - 用
runtime.ReadMemStats对比Alloc和TotalAlloc可实测差异
什么时候必须用 []*T？
不是“性能更好”才选它，而是语义需要：你要共享、延迟初始化、或 T 本身不能复制（比如含 sync.Mutex 字段的结构体）。
容易被忽略的点：json.Unmarshal 对 []*T 默认不会自动 new 每个 *T，解码前得手动初始化，否则 panic。
- 必须用
[]*T：要对切片中某些元素调用方法并修改其字段（且T方法集含指针接收者） - 必须用
[]*T：T包含不可复制字段（如sync.WaitGroup） - 别硬套：
[]string几乎永远比[]*string更合理——string本身是小结构体（16B），复制便宜，且不可变
真正复杂的地方不在大小计算，而在所有权和生命周期——[]*T 让你承担更多内存管理责任，一不留神就是悬垂指针或意外共享。
