结构体≤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，确认参数是否真在栈上

指针带来的隐性成本常被忽略

传指针省了复制，但可能换来更贵的代价：

• 解引用本身虽快，但若 *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 字段传指针反而多一次内存跳转——这些细节，只有压测和逃逸分析能告诉你。