本文深入分析在处理大规模（如百万级）结构体集合时，选择 `[]t` 还是 `[]*t` 的关键考量：涵盖内存复制开销、gc 压力、排序/删除/传递行为差异，并结合实测数据给出可落地的工程建议。
在 Go 中，切片底层是一个指向底层数组的指针、长度和容量三元组。当你定义 []MyStruct 时，切片元素本身是完整的结构体副本；而 []*MyStruct 存储的则是固定大小（通常为 8 字节）的指针。二者在内存布局、操作语义和运行时开销上存在本质差异——尤其当元素规模达百万量级且高频操作（append、sort、遍历、传参）时，这些差异会显著影响性能与资源消耗。
✅ 核心性能对比：复制成本是关键瓶颈
结构体大小直接决定复制开销。以问题中示例结构体（含 6 个 int/string 字段 + 1 个 []SomeType 切片字段）为例，其大小远超指针（unsafe.Sizeof(&MyStruct{}) == 8）。每次 append 触发底层数组扩容时，[]MyStruct 需要逐个复制整个结构体到新数组；而 []*MyStruct 仅复制指针，速度提升数倍。如下基准测试结果极具代表性：
type MyStruct struct {
F1, F2, F3, F4, F5, F6, F7 string
I1, I2, I3, I4, I5, I6, I7 int64
}
func BenchmarkAppendingStructs(b *testing.B) {
var s []MyStruct
for i := 0; i < b.N; i++ {
s = append(s, MyStruct{})
}
}
func BenchmarkAppendingPointers(b *testing.B) {
var s []*MyStruct
for i := 0; i < b.N; i++ {
s = append(s, &MyStruct{})
}
}运行结果（典型 x86-64 环境）：
BenchmarkAppendingStructs 1000000 3528 ns/op // ≈ 3.5ms per 1M appends BenchmarkAppendingPointers 5000000 246 ns/op // ≈ 1.2ms per 1M appends
→ 指针切片追加速度快 14 倍以上。即使预分配容量（make([]MyStruct, 0, 1e6)）消除扩容拷贝，结构体切片仍比指针切片慢约 4×（因每次 append 仍需复制值）。
⚠️ 不可忽视的权衡点：GC 与内存局部性
- GC 压力：[]*MyStruct 将百万个结构体对象分散堆上，增加 GC 扫描对象数与标记时间。但现代 Go GC（v1.21+）已高度优化，对百万级小对象压力可控；真正需警惕的是长期存活且频繁逃逸的小对象。若结构体生命周期与切片一致（即随切片释放），GC 影响常被高估。
- 内存局部性：[]MyStruct 元素连续存储，CPU 缓存友好，遍历时 for _, v := range s 性能极佳；[]*MyStruct 则导致随机内存访问，可能引发大量缓存未命中。读多写少场景下，结构体切片的遍历优势可能抵消指针切片的 append 优势。
- 语义清晰性：[]MyStruct 传递的是值，天然线程安全（无共享状态风险）；[]*MyStruct 传递指针，需谨慎避免意外修改或数据竞争。
? 实用决策指南（按优先级排序）
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 结构体 ≤ 32 字节（如 type Point struct{X,Y int}） | []T | 复制开销极小，缓存友好，代码简洁，GC 无压力 |
| 结构体 > 64 字节 + 频繁 append/sort/delete | []*T | 复制成本主导性能，指针操作收益显著（如问题中百万级场景） |
| 高频只读遍历 + 结构体较大 | 先压测！[]T vs []*T | 局部性可能胜过复制开销，用 go test -bench=. 验证真实负载 |
| 需保证不可变性或避免意外修改 | []T | 值语义杜绝副作用，适合配置、DTO 等场景 |
| 结构体含大字段（如 []byte, map, chan） | []T（通常更优） | 这些字段本身是指针，[]T 仅复制少量元数据，实际内存不重复 |
? 工程提示：对 []*MyStruct，务必确保结构体分配不逃逸到堆外作用域（如避免返回局部变量地址），并考虑使用 sync.Pool 缓存临时结构体以减轻 GC 压力（适用于短生命周期对象）。
? 总结：没有银弹，但有清晰路径
百万级元素并非“不大”——它足以让微小的每元素开销（如 3000ns vs 250ns）累积成毫秒级延迟差异。优先测量，而非猜测：用 go test -bench 覆盖你的典型操作链（append → sort → range → delete）。若基准显示 []*T 在关键路径快 2× 以上，且 GC profile（go tool pprof）未报警，则果断采用；若读性能敏感且结构体适中，[]T 仍是更稳健、更 Go-idiomatic 的选择。记住：Go 的设计哲学是“明确优于隐晦”，让选择服务于可维护性，而不仅是峰值性能。
