指针函数和值函数调用效率差异取决于结构体的unsafe.Sizeof大小、字段类型、内存对齐及是否逃逸；需用testing.B基准测试并避开内联、未报告分配、未使用结果三大陷阱。

指针函数和值函数的调用效率差别不是固定值，它完全取决于结构体的 unsafe.Sizeof 实际大小、字段类型、内存对齐，以及是否触发逃逸——不测，就只能猜；一测，常会推翻直觉。

怎么写一个不被编译器骗的 Benchmark

手写 time.Now() 测单次耗时毫无意义。Go 的 testing.B 机制才是唯一靠谱起点，但必须避开三个默认陷阱：

• 不加 -gcflags="-l"：编译器内联会让两个版本都“消失”，BenchmarkByValue 和 BenchmarkByPointer 可能跑出几乎一样的 ns/op，实际根本没在测传参
• 不加 b.ReportAllocs()：你看不到值传递是否悄悄逃逸到堆上——比如一个 struct{ Name string; Data []byte } 看似才 48 字节，但内部 string header 指向的底层数组一旦被修改，就会触发额外分配
• 循环里没用结果：写成 useValue(s) 而不是 _ = useValue(s)，Go 1.21+ 编译器真会把整行删掉，最后跑出 0.12 ns/op 这种假数据

结构体多大才算“该用指针”？看字节，别数字段

字段数量、是否含 string 或 []byte 都是干扰项。真正起作用的是 unsafe.Sizeof 返回的连续内存块大小（含填充）：

• type Point struct{ X, Y int64 } → 16 字节：值传递通常快 5–10%，解引用反而拖慢缓存命中
• type Config struct{ Host string; Port int } → 32 字节（string header 16 + int 8 + padding 8）：两者差距收窄，ns/op 差通常
• type Heavy struct{ ID int64; Data [256]byte; Tags map[string]int } → ≥ 320 字节：指针传递稳定快 3–5 倍，且 allocs/op 低一个数量级

注意：string 和 []byte 值传递只拷贝 24 字节 header，但只要函数内发生拼接、append 或 map 写入，底层 backing array 就可能被复制——这时“小结构体”的幻觉立刻破灭。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

立即学习“go语言免费学习笔记（深入）”；

为什么有时候指针反而更慢？三个真实坑

指针不是性能银弹。以下情况会让它在热点路径里吃亏：

• 解引用链过长：(*s).cfg.opts.timeout 在 tight loop 中比值类型直接访问慢，CPU 多一次内存加载，L1 cache miss 概率上升
• 强制逃逸：哪怕你传的是 *T，如果函数内把该指针存进全局 map 或返回给调用方，整个 T 就会逃逸到堆——这时你省了传参拷贝，却换来 malloc + GC 压力
• sync.Mutex 类型必须传指针：这不是性能问题，是编译错误。值传递 sync.Mutex 会触发 copy of locked mutex panic，连测试都跑不起来

最常被忽略的一点：方法接收器选择（func (T) Foo vs func (*T) Foo）会同时影响接口实现和性能。哪怕结构体只有 12 字节，如果你要用它实现某个接口，而该接口方法恰巧用了指针接收器，那值传递就直接断路——性能还没测，代码先报错。