必须用go build -gcflags="-m -l"查看真实逃逸路径：-m输出内存分配决策，-l禁用内联确保定位准确；关键看does not escape（栈分配）、moves to heap（指针逃逸）、leaking param（参数外泄）三类提示。
用 go build -gcflags="-m -l" 看逃逸和拷贝行为
编译器不会告诉你“这个结构体传值慢”，但会明确指出变量是否逃逸、是否被复制。加 -m 输出内存分配决策，-l 禁用内联让结果更真实：
-
./main.go:12:6: s does not escape→ 变量留在栈上，值传递无额外开销 -
./main.go:15:10: &u moves to heap→ 指针导致原结构体逃逸，GC 开始介入 -
./main.go:8:12: leaking param: u→ 参数被返回或存入全局变量，强制堆分配
注意：没输出任何逃逸提示，不代表值传递就一定比指针快——它只说明“没逃”，但大结构体的栈拷贝仍存在。要结合 unsafe.Sizeof 判断实际拷贝量。
用 go test -bench=. 实测吞吐与分配次数
性能不是猜出来的。写两个基准测试函数，一个用 func f(v MyStruct)，一个用 func f(v *MyStruct)，跑 go test -bench=. -benchmem：
- 关注
BenchmarkXXX-8 1000000 1245 ns/op 0 B/op 0 allocs/op中的allocs/op—— 值传递若出现非零值，大概率是结构体太大触发了隐式堆分配（比如含map或slice字段） - 对比
ns/op差距：实测显示，unsafe.Sizeof(MyStruct{}) == 128时，指针版本通常快 1.5–2.2×；但若结构体仅 8 字节（如struct{ X, Y int32 }），值版本反而快 10–15% - 别忽略
-cpu参数：加-cpu=1,4,8看并发下 false sharing 是否浮现（多个 goroutine 频繁修改同一缓存行里的不同字段）
用 unsafe.Sizeof 和字段构成判断是否真“大”
结构体大小不能只看字段数。Go 的 unsafe.Sizeof 返回的是对齐后的字节数，它决定栈拷贝成本：
立即学习“go语言免费学习笔记（深入）”；
-
type User struct{ ID int; Name string }→unsafe.Sizeof是 32 字节（string是 16 字节 header），值传递每次拷贝 32 字节 -
type Config struct{ Data [1024]byte; Meta map[string]string }→unsafe.Sizeof是 1040+ 字节（mapheader 8 字节 + 对齐填充），值传递等于每调用一次就拷贝 1KB 栈内存 -
type Packet struct{ Header [8]byte; Payload []byte }→unsafe.Sizeof仅 32 字节（[]byteheader 是 24 字节），但Payload底层数组不拷贝；这种结构体值传递其实很轻量，不必强上指针
真正该警惕的是：结构体含 sync.Mutex、[4096]int、或多个嵌套大数组——它们会让 unsafe.Sizeof 直接突破 64 字节阈值，此时指针几乎总是更优。
接口实现时方法接收者类型影响调用开销
你可能没在函数签名里写指针，但接口调用时 Go 会自动补上。比如：
type Reader interface { Read(p []byte) (n int, err error) }
func process(r Reader) { r.Read(buf) }
如果 User 类型只有 func (u User) Read(...)，那 process(User{}) 就会拷贝整个 User；但如果改成 func (u *User) Read(...)，process(&u) 就只传地址。更隐蔽的是：
-
var _ Reader = (*User)(nil)成立，但var _ Reader = User{}不一定成立——取决于Read方法是否定义在*User上 - 高频接口调用（如 HTTP handler 中的
io.Reader）中，值接收者会导致每次装箱都拷贝结构体，而指针接收者只拷贝地址 - 如果结构体实现了多个接口，且其中部分方法用值接收者、部分用指针接收者，那么传值可能无法满足所有接口要求，编译失败
最易被忽略的一点：接口变量本身是 16 字节（类型+数据指针），但它的“数据”部分如果是值类型，就包含完整结构体；如果是指针，则只是个地址。这点在 pprof 分析时经常被误读为“接口开销大”，其实是接收者类型选错了。
