在Go语言的实际开发过程中，当我们需要存储一组同类型的结构体数据时，经常会面临两个选择：使用结构体切片还是结构体指针切片。这两种方式在底层实现、运行表现和适用场景上都有明显区别，需要从性能、内存、GC等多个角度综合权衡。
两种切片的基础定义与内存布局
结构体切片存储的是结构体本身的实例，而结构体指针切片存储的是指向结构体实例的指针。我们可以通过简单的代码示例来看两者的定义方式：
package main
import "fmt"
// 定义一个简单的用户结构体
type User struct {
ID int
Name string
Age int
}
func main() {
// 结构体切片定义与初始化
userSlice := []User{
{ID: 1, Name: "张三", Age: 20},
{ID: 2, Name: "李四", Age: 22},
}
// 结构体指针切片定义与初始化
userPtrSlice := []*User{
{ID: 3, Name: "王五", Age: 25},
{ID: 4, Name: "赵六", Age: 28},
}
fmt.Println("结构体切片第一个元素：", userSlice[0])
fmt.Println("结构体指针切片第一个元素：", userPtrSlice[0])
}
从内存布局来看，结构体切片的所有元素会连续存储在内存中，每个元素的大小等于结构体的大小。而结构体指针切片存储的是指针值，指针本身大小固定（64位系统下为8字节），指针指向的结构体实例可以分布在堆内存的不同位置，不需要连续存储。
性能维度的对比
数据访问与修改性能
结构体切片访问元素时，直接通过偏移量就能拿到完整的结构体数据，不需要额外的指针解引用操作。而结构体指针切片访问元素时，需要先拿到指针，再解引用才能得到结构体数据，多了一次内存访问操作。
在修改切片元素时，两者的表现也有差异：
func modifyUser() {
userSlice := []User{
{ID: 1, Name: "张三", Age: 20},
}
userPtrSlice := []*User{
{ID: 2, Name: "李四", Age: 22},
}
// 修改结构体切片元素，直接修改即可
userSlice[0].Age = 21
// 修改结构体指针切片元素，同样直接通过指针修改
userPtrSlice[0].Age = 23
}
如果是对切片本身进行追加操作，结构体切片追加时如果容量不足，会重新分配一块更大的连续内存，把原有元素拷贝到新内存中。而结构体指针切片追加时，只需要拷贝指针值，不需要拷贝结构体本身的内容，当结构体体积较大时，指针切片的追加效率会更高。
函数传参性能
切片本身作为引用类型，传参时只会拷贝切片的头部信息（指向底层数组的指针、长度、容量），不会拷贝底层元素。如果是结构体切片传参，函数内部修改元素会直接影响原切片的元素；如果是结构体指针切片传参，修改指针指向的结构体内容同样会影响原数据，但如果是修改切片内的指针值（比如替换某个指针指向新的结构体），不会影响原切片的指针内容。
内存占用维度的对比
结构体切片的内存占用等于所有结构体实例的总大小之和，没有额外的指针开销。而结构体指针切片的内存占用等于所有指针的大小之和，加上所有结构体实例的大小之和，多了一层指针的内存开销。
我们可以通过一个简单的对比来看不同结构体大小下的内存差异：
package main
import (
"fmt"
"unsafe"
)
type SmallStruct struct {
A int // 8字节
}
type LargeStruct struct {
A [1024]byte // 1024字节
}
func main() {
smallSlice := make([]SmallStruct, 1000)
smallPtrSlice := make([]*SmallStruct, 1000)
for i := 0; i < 1000; i++ {
smallPtrSlice[i] = &SmallStruct{}
}
largeSlice := make([]LargeStruct, 1000)
largePtrSlice := make([]*LargeStruct, 1000)
for i := 0; i < 1000; i++ {
largePtrSlice[i] = &LargeStruct{}
}
fmt.Println("小结构体切片大小：", unsafe.Sizeof(smallSlice), "指针切片大小：", unsafe.Sizeof(smallPtrSlice))
// 实际元素内存需要额外计算，小结构体场景下结构体切片总内存更小
// 大结构体场景下，指针切片的元素拷贝开销更低，但总内存会比结构体切片多指针部分
}
当结构体本身体积很小时，结构体切片的总内存占用会低于结构体指针切片，因为省去了指针的开销。当结构体体积较大时，结构体切片的总内存和指针切片的总内存差异主要体现在指针的额外开销上，此时两者的总内存差距相对结构体本身的大小来说占比很小。
GC影响维度的对比
Go语言的垃圾回收器需要扫描堆上的对象，判断哪些对象还在被引用，哪些可以被回收。结构体切片如果存储在栈上，其元素会随着栈的销毁而释放，不需要GC参与；如果结构体切片被逃逸到堆上，那么整个底层数组会被GC扫描，但是因为元素是连续存储的，扫描效率较高。
结构体指针切片中的指针指向的结构体实例都分布在堆上，GC需要扫描每个指针，判断其指向的对象是否存活，当指针数量很多时，会增加GC的扫描工作量，提升GC的压力。如果指针切片中的指针大量指向不同的对象，GC的标记阶段需要遍历更多的对象，可能会导致GC停顿时间变长。
不同场景的选择建议
- 如果结构体体积很小，且需要频繁访问、修改元素，优先选择结构体切片，减少指针解引用开销和GC压力。
- 如果结构体体积较大，且需要频繁对切片进行追加、插入、删除等操作，优先选择结构体指针切片，减少元素拷贝的开销。
- 如果切片需要作为函数参数传递，且函数内部可能需要替换切片中的某个元素为新的结构体实例，优先选择结构体指针切片，避免结构体切片的拷贝问题。
- 如果结构体实例需要被多个地方共享引用，优先选择结构体指针切片，这样多个引用指向同一个实例，修改时可以同步生效，也避免多份实例的内存浪费。
总结
结构体切片和结构体指针切片没有绝对的好坏之分，核心是根据实际的业务场景，从性能、内存、GC三个维度综合判断。小结构体、高频访问修改的场景适合结构体切片；大结构体、高频变更切片结构、多引用共享的场景适合结构体指针切片。在实际开发中，也可以结合基准测试来验证两种选择的实际表现，做出更贴合需求的决策。