Golang指针与切片性能对比解析

本文深入剖析了Go语言中切片与结构体传参的核心性能权衡：切片传值高效且安全，因其仅复制24字节的header而共享底层数组，而盲目使用*[]T不仅引入解引用、nil检查和语义混淆等陷阱，实际收益极小；结构体是否传指针则应基于真实大小、修改需求和基准测试结果综合判断——小结构体传值更优，大结构体或需写入时才考虑指针，绝非“一律用指针”的教条；最终强调，真正的性能瓶颈往往不在参数传递方式，而在切片元素类型（[]T vs []*T）及底层内存操作，唯有通过go test -bench实测才能避免直觉误导，做出精准优化决策。

传切片不用特意传指针，除非你真需要让函数修改切片头（比如 append 后让调用方看到扩容结果）；而传大结构体时，指针确实能省掉几十到几百字节的拷贝——但小结构体传值反而更干净、更快。

为什么切片传值就足够，*[]T 反而是陷阱？

因为切片本身只是 24 字节的 header（ptr + len + cap），传值只复制这三部分，底层数组仍共享。所以：

• s[0] = 123 会改原数组 —— 没问题
• s = append(s, x) 只改副本，调用方完全感知不到 —— 这是常见 bug 源头
• 传 *[]T 能解决扩容可见性问题，但代价是：每次访问都要解引用（*s）、必须判 nil、不能直接用 range s（得写 range *s），还容易和 []*T 混淆

真正该用 *[]T 的场景极少，比如实现一个「动态填充并返回新切片」的初始化函数，且不希望调用方写 s = f(s)。

什么时候必须传指针？看结构体大小和修改意图

结构体是否传指针，关键不是“它是不是复杂类型”，而是：拷贝成本 vs 解引用开销 vs 是否要写回。

• 小结构体（如 type Point struct{ X, Y int }，unsafe.Sizeof ≤ 16 字节）：传值更高效，CPU 缓存友好，无 nil 风险
• 中大型结构体（含字符串、切片、嵌套结构，或字段 > 6 个）：传指针可避免每次 append/sort 时复制整块内存
• 只要函数里要改结构体字段（比如 u.Name = "x"），就必须传指针；只读场景下，值传递语义更清晰

别被“结构体默认要传指针”的经验带偏——Go 标准库大量使用值传递的小结构体（如 time.Time、sync.Mutex）。

性能差异到底有多大？别猜，用 go test -bench 验证

实测比拍脑袋有用得多。例如对比：

func BenchmarkAppendStruct(b *testing.B) {
    for i := 0; i 
结果往往差 10 倍以上。但注意：append 开销主要来自扩容时的底层数组复制，不是 header 拷贝；而 *[]T 并不会减少这个开销，只影响切片头本身是否更新。

最容易被忽略的一点：切片元素用 []T 还是 []*T，对百万级数据的 sort 或 append 影响远大于传参方式的选择——后者决定的是“怎么传”，前者决定的是“传什么”。
今天关于《Golang指针与切片性能对比解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！