传递大型结构体必须用指针，否则触发完整内存拷贝，引发栈溢出、GC压力剧增；超16字节优先用*Struct；注意指针逃逸会强制堆分配，可用go build -gcflags="-m -l"检测；高频大对象应结合sync.Pool复用指针实例。
为什么传递大型结构体时一定要用指针
直接传值会触发完整内存拷贝，比如一个 2MB 的 struct，每次函数调用都复制一次，CPU 和内存带宽压力陡增。Go 的栈空间默认只有 2KB（小对象）到几 MB（大 goroutine），超限直接 panic：stack overflow。更隐蔽的问题是 GC 压力——大量临时副本会快速填满年轻代，触发频繁的 minor GC。
实操建议：
- 只要结构体字段总大小超过 16 字节（如含多个
string、[]byte或嵌套 struct），就优先用*MyStruct传参 - 方法接收者也同理：修改状态或结构体较大时，用指针接收者（
func (s *MyStruct) Update()），否则只读且小结构可用值接收者 - 注意：
string和slice本身是 header（24 字节），传值开销小，但它们指向的底层数组仍可能很大——此时是否用指针取决于你是否要修改 header（如重切片）或底层数组内容
避免指针逃逸导致堆分配
你以为用了指针就能省内存？不一定。如果编译器判定该指针“逃逸”（escape）出当前函数作用域（比如被返回、存入全局 map、传给 goroutine），它就会把原本在栈上的变量强制分配到堆上，延长生命周期，增加 GC 负担。
查逃逸的方法：go build -gcflags="-m -l"。常见逃逸场景：
立即学习“go语言免费学习笔记（深入）”；
- 返回局部变量的地址：
return &localStruct - 将局部变量地址存入切片/映射：
list = append(list, &item) - 传给以接口类型定义的函数（如
fmt.Println接收interface{}）
优化方向：尽量让指针生命周期局限在函数内；若必须返回，考虑改用 ID + 全局池（如 sync.Pool）复用对象，而非反复 new。
sync.Pool 配合指针复用，减少高频分配
处理大量短生命周期的大对象（如解析 JSON 的 *User、网络包缓冲区）时，每请求 new 一次，GC 很快吃不消。用 sync.Pool 管理指针对象实例，能显著降低堆分配频率。
示例：
var userPool = sync.Pool{
New: func() interface{} {
return new(User) // 注意：返回的是 *User，不是 User
},
}
func handleRequest() {
u := userPool.Get().(*User)
defer userPool.Put(u) // 放回前确保字段已重置（如 u.ID = 0）
// ... 使用 u
}
关键点：
-
sync.Pool不保证 Get 一定拿到旧对象，也可能 new 新的，所以每次使用前需显式清空业务相关字段 - 不要把含 finalizer 或依赖析构逻辑的对象放进 Pool（回收不可控）
- Pool 是 per-P 的，高并发下竞争低，但注意不要滥用——小对象（
unsafe.Pointer 能不能用来绕过拷贝
能，但极度不推荐用于常规大数据处理。它绕过 Go 类型系统和 GC 管理，容易造成悬垂指针、内存泄漏或崩溃。比如用 unsafe.Pointer 强转 []byte 底层数据给 C 函数处理后，原 slice 若被 GC 回收，C 侧继续读写就是未定义行为。
仅在极少数场景可谨慎考虑：
- 零拷贝序列化（如
gogoprotobuf内部优化） - 与 C 交互且明确控制内存生命周期（配合
C.malloc/C.free） - 性能敏感的底层库（如网络协议栈），且有完备测试和内存安全审计
绝大多数业务代码里，老实用 *T + sync.Pool 就够了。真正卡在内存拷贝上时，先 profile 看是不是算法或数据结构设计问题——比如用 []*BigItem 存指针数组，比 []BigItem 复制整个数组好得多。
