结构体≤24 字节优先值传递，含大数组 / 需修改字段 / 并发安全等场景用指针；须用 unsafe.Sizeof 测真实大小、-benchmem 对比基准、-gcflags=”-m -m” 查逃逸，避免误判。
不是一定更高效。结构体小于约 64字节 时，func f(u User) 常比 func f(u *User) 更快；超过 128 字节后，指针传递才稳定胜出。性能拐点取决于大小、字段类型、CPU 缓存行为和编译器优化，不能靠经验拍板。
怎么快速判断该传值还是传指针
先用 unsafe.Sizeof 看结构体真实大小，再结合使用场景做决策：
- 结构体 ≤ 24 字节（约 3 个
int64或 2 个string）：优先值传递，缓存友好，避免解引用延迟 - 含大数组（如
[1024]byte）、切片、map、长字符串等：哪怕总大小不大，也要传指针——因为这些字段的 header 虽小，但函数内若触发append或make，可能意外修改原数据或扩容逃逸 - 方法接收者需修改字段（如
u.Save()）：必须用指针，值接收者无法持久化变更 - 只读高频调用（如
u.String()）且结构体 ≤ 16 字节：值接收者更利于内联和 栈驻留，实测常快 10%~20%
基准测试不写对，结果就全错
Go 的逃逸分析会显著干扰测试结果。比如本该栈分配的 User，因传了指针被强制堆分配，allocs/op 暴涨，反而掩盖了复制节省的优势。
- 务必加
-benchmem：看BenchMarkXXX-8 10000000 123 ns/op 0 B/op 0 allocs/op才算干净 - 对比要成对：同时测
func(u User)和func(u *User)，输入都从同一变量取，避免初始化偏差 - 禁用内联干扰：加
//go:noinline防止编译器把小函数直接展开，导致值传递“看起来更快” - 查逃逸：运行
go build -gcflags="-m -m" main.go，确认参数是否真在栈上
指针带来的隐性成本常被忽略
传指针省了复制，但可能换来更贵的代价：
立即学习“go 语言免费学习笔记（深入）”；
- 解引用本身虽快，但若
*User分布在不同内存页，频繁访问u.Name、u.ID可能引发多次 cache miss - 多个 goroutine 共享同一
*User并并发写字段，不加锁就是数据竞争——而值传递天然线程安全 -
nil检查漏掉？panic: runtime error: invalid memory address or nil pointer dereference在生产环境深夜炸出来 - 返回局部结构体地址：
return &User{……}看似方便，实际每次调用都 new 堆对象，GC 压力肉眼可见
真正影响性能的从来不是“用不用指针”，而是你有没有看清数据规模、访问模式和生命周期。一个 [1024]byte 字段能让值传递慢 10 倍，而三个 int 字段传指针反而多一次内存跳转——这些细节，只有压测和逃逸分析能告诉你。
