大结构体传指针反而更慢，因interface{}参数触发逃逸致堆分配，反射访问或字段顺序不当也会引发冗余拷贝；小结构体（≤16字节且无指针）传值更快。
为什么大结构体传指针反而更慢？
不是所有大对象传指针都省事。Go 的函数调用约定里，interface{} 或空接口参数会触发逃逸分析强制堆分配，哪怕你传的是 *BigStruct，只要它被装进 fmt.Println、log.Printf 这类接受 interface{} 的函数，底层仍可能复制整个结构体字段（尤其是含大数组或切片底层数组时）。更隐蔽的是：如果结构体含未导出字段且被反射访问（比如 json.Marshal），编译器可能放弃优化，导致冗余拷贝。
- 实操建议：用
go build -gcflags="-m" main.go看关键函数是否逃逸；若出现... escapes to heap，说明传指针没拦住分配 - 避免把大结构体直接塞进
fmt、log、encoding/json等泛型接口函数——先提取必要字段打日志，或实现自定义String()方法 - 结构体字段顺序影响逃逸：把大字段（如
[1024]byte）放最后，小字段（int、*sync.Mutex）放前面，能降低小字段触发整块内存逃逸的概率
什么时候该传值而不是指针？
小于机器字长（通常是 8 字节）的结构体，传值比传指针更快。因为 CPU 寄存器能一次载入，而指针还要多一次解引用。典型例子：time.Time（24 字节，但内部含指针）、sync.Once（单个 uint32）、甚至带两个 int64 的小结构体（16 字节）在现代 CPU 上也常比指针快——因为避免了 cache line miss 和间接寻址开销。
- 判断依据：用
unsafe.Sizeof(T{})测大小；≤ 16字节且不含指针/切片/map/channel 的结构体，优先传值 - 注意
struct{ a int; b [8]byte }是 16 字节，但struct{ a [8]byte; b int }可能因对齐变成 24 字节——用go tool compile -S看实际栈分配量 - 方法接收者同理：小结构体用值接收者，避免无谓的
*T解引用；大结构体才用指针接收者保证一致性
切片和 map 的“假大对象”陷阱
切片和 map 本身很小（slice 是 24 字节，map 是 8 字节），传值开销可忽略。真正占内存的是它们背后的底层数组或哈希表。所以别给切片传指针——*[]int 不仅不省内存，还增加解引用成本，且破坏 Go 的惯用写法（比如无法用 append 直接扩容）。
- 正确做法：传
[]int或map[string]int本体；需要修改底层数组内容时，靠函数内操作原切片即可（因为切片头含指向底层数组的指针） - 唯一需传
*[]T的场景：函数要替换整个切片头（比如重新make并赋值给原变量），但这属于边界情况，多数时候是设计缺陷 -
map同理：传map值就能增删改查；传*map只在需要nil判定后重建整个 map 时才用（极少见）
逃逸分析失效的三个高危操作
即使你老老实实传指针，以下操作会让编译器放弃优化，导致大对象被意外拷贝到堆上：
立即学习“go语言免费学习笔记（深入）”；
- 把局部结构体地址取出来传给
goroutine：比如go f(&s)，编译器无法确定 goroutine 生命周期，强制逃逸 - 结构体嵌套指针字段但初始化时用了字面量：如
&MyStruct{Data: make([]byte, 1e6)}，大底层数组会随结构体一起逃逸 - 用
reflect.ValueOf包裹指针：反射会绕过编译器的逃逸判断，直接触发堆分配
最稳妥的做法是：用 go run -gcflags="-m -l" main.go（-l 关闭内联干扰）逐行验证关键路径；看到 moved to heap 就得回溯调用链，而不是凭经验猜。
