指针和值的性能差异取决于结构体大小、访问模式、是否逃逸、编译器优化级别四个变量；实测显示临界点在64–128字节之间，小结构体值传更快，大结构体指针更优，但需结合逃逸分析与基准测试综合判断。
直接说结论：指针和值的性能差异不是固定快慢，而是取决于结构体大小、访问模式、是否逃逸、编译器优化级别这四个变量。不测，就别信“指针一定更快”这种经验说法。
怎么写一个靠谱的 Go 基准测试（go test -bench）
Go 自带的 testing.B 是最轻量也最可靠的起点，关键在控制变量：
- 每次只改一个因素：比如只变结构体大小，其他全保持一致
- 避免编译器把整个循环优化掉——在循环体内加无副作用但不可省略的操作，如
blackhole(result) - 用
go test -gcflags="-m" -bench=.看变量是否逃逸到堆上，因为堆分配会掩盖传参本身的开销 - 结构体字段顺序要固定（比如把
string放最后），否则内存对齐差异会影响结果
func BenchmarkPassMediumStructByValue(b *testing.B) {
s := Medium{ID: 1, Name: "test", Data: [64]byte{}}
for i := 0; i < b.N; i++ {
_ = useMediumValue(s) // 必须有实际返回或使用，否则可能被优化
}
}
func BenchmarkPassMediumStructByPointer(b *testing.B) {
s := &Medium{ID: 1, Name: "test", Data: [64]byte{}}
for i := 0; i < b.N; i++ {
_ = useMediumPtr(s)
}
}
结构体多大才算“大”？看实测阈值，不是拍脑袋
实测数据（amd64 / Go 1.23）显示临界点在 64–128 字节之间，但具体数值依赖字段类型和对齐：
-
[16]byte或struct{int64; string}（约 32 字节）：值传递通常快 5–10% -
[64]byte或含 slice 的小 struct（约 80 字节）：两者耗时差 -
[256]byte或嵌套 map/string（> 300 字节）：指针传递稳定快 3–5 倍，且 GC 压力开始明显上升
注意：string 和 slice 本身是 header（24 字节），值传递只拷贝 header，不是底层数组——这点常被误判为“小结构体”。真正代价来自底层 backing array 的复制（仅当发生切片扩容或字符串修改时）。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
为什么有时候指针反而更慢？三个典型坑
指针不是银弹，以下情况会让它吃亏：
-
解引用链过长：比如
(*s).field1.sub.field2在 hot path 中比值类型直接访问慢，CPU 要多走一次内存加载 -
强制逃逸：即使你传的是
*T，如果函数内把该指针存进全局 map 或返回给调用方，整个T就会逃逸到堆，带来分配+GC 开销 - 缓存局部性破坏：值传递让数据留在栈上，CPU 缓存命中率高；而指针指向的结构体若分散在堆各处，连续访问多个字段可能触发多次 cache miss
验证方式很简单：go build -gcflags="-m -l" main.go，看输出里有没有 ... moves to heap。
真正的性能决策从来不是查文档，而是跑出自己的 BenchmarkXxx，再结合 -gcflags="-m" 和 pprof 看真实行为。结构体大小、是否含引用类型、是否高频调用、是否需修改原值——这些条件组合起来，才决定该用 T 还是 *T。漏掉任意一个，结论都可能翻车。
