Go 里的指针传递一定比值传递快吗？实战性能测试对比-Golang-PHP中文网

结构体≤16字节值传递通常更快；真正决定性能的是unsafe.Sizeof所得实际大小，而非字段数或直觉；逃逸分析影响远超传值/传指针选择。

结构体多大才算“大”？看 `unsafe.Sizeof`，别猜

go 里传指针不一定更快——小结构体（≤16 字节）值传递通常反超，因为避免了解引用、缓存未命中和潜在逃逸。真正起决定作用的是结构体在内存中的实际布局大小，不是字段个数或直觉判断。

用 unsafe.Sizeof 查真实体积，例如：

type Point struct{ X, Y int64 }        // → 16 字节
type Config struct{ Host string; Port int } // → 32 字节（string header 16 + int 8 + padding）
type Heavy struct{ ID int64; Data [64]byte; Tags []string } // → 160+ 字节（含对齐填充）

≤16 字节：值传递大概率更快，尤其在热点路径（如 HTTP 中间件）
64–128 字节：两者性能差通常
≥256 字节：指针传递稳定快 3–5 倍，且 GC 压力开始明显上升

基准测试怎么写才不被编译器骗？加 `-gcflags="-m -l"` 和 `b.ReportAllocs()`

只跑 go test -bench=. 很可能得到假阳性结果：编译器内联、变量逃逸、循环优化都会掩盖真实开销。

必须做三件事：

禁用内联：go test -gcflags="-l" -bench=.，否则 byValue 和 byPointer 可能都被抹平
查逃逸：go test -gcflags="-m -l" -bench=.，重点看 escapes to heap —— 如果值传递也逃逸了，那“省拷贝”的前提就不存在
统计堆分配：b.ReportAllocs() 加进 benchmark 函数，确认是否因传参触发额外 malloc

错误示范：_ = f(s) 可能被优化掉；正确写法是把返回值赋给全局变量 globalResult = f(s)，防止消除。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

含 `[]byte`、`map`、`string` 的结构体，值传递不等于“小”

string 和 []byte 是 header（24 字节），值传递只拷贝 header，但这是个典型认知陷阱：header 里存着指向底层数组的指针，一旦函数内发生切片扩容、字符串拼接或 map 写入，就会触发 backing array 复制或新堆分配。

结构体本身 40 字节，但含一个 map[string]int → 值传递复制 map header（8 字节），但后续任意写操作都可能让底层 hash table 重新分配
结构体含 []string，即使整体 unsafe.Sizeof 是 56 字节，append 操作仍会修改共享底层数组，造成意外交互
哪怕结构体只有两个字段，只要含 sync.Mutex，就必须传指针——否则编译直接报错

这类结构体，传指针不只是为了性能，更是为了语义可控和避免隐式共享。