Go语言中值拷贝是默认行为，但大结构体、切片、map或含指针字段类型应慎用；需根据是否修改原数据、是否高频调用、底层数据量大小判断是否改用指针传参，同时注意逃逸分析与真实性能瓶颈。
Go 语言中值拷贝是默认行为，但不是所有场景都需要——尤其对大结构体、切片、map 或含指针字段的类型，盲目传值会带来可观的内存分配和 CPU 开销。关键判断依据是：是否需要修改原数据？是否在高频路径（如循环、HTTP handler）中调用？是否类型底层包含大量数据（比如 []byte 超过几百字节）？满足任一，就该考虑避免拷贝。
什么时候必须用指针传参而不是值传参
函数参数接收大结构体（如字段超过 4 个、含 []string 或 map[string]int）时，值传参会触发完整内存复制；而指针只传 8 字节地址。但注意：指针不是万能解药——若函数内部只读且编译器能做逃逸分析优化（例如小结构体在栈上分配），值传参反而更快。
- 结构体大小 > 128 字节（经验值，可借助
unsafe.Sizeof验证）应优先考虑指针 - 含 slice、map、chan、func 或 interface{} 字段的结构体，值拷贝会复制头信息，但底层数组/哈希表仍共享，容易引发并发读写 panic，此时必须用指针 + 显式深拷贝（如需隔离）或加锁
- 方法接收者：如果方法会修改字段，必须用指针接收者（
func (p *MyStruct) Mutate()）；否则值接收者即可，无需强行改指针
切片和 map 的“假拷贝”陷阱
Go 中 []T 和 map[K]V 本身是指针包装类型，传参时复制的是 header（含指针、len、cap 或 hash 表引用），不是底层数组或哈希桶。所以它们“看起来像值传递，实则共享底层”。这既是便利也是隐患。
- 向函数传
[]int并在内部append，可能触发底层数组扩容，新数组与原切片不再共享数据——但原切片长度不变，容易误判修改生效 - 传
map[string]int给函数并修改 key，原 map 确实被改；但如果函数内做了m = make(map[string]int)再赋值，外部 map 不受影响（因为只改了副本 header） - 安全做法：若函数需保证不污染输入，且逻辑复杂，显式传
*[]T或*map[K]V；更推荐重构为返回新值（函数式风格），如newSlice := filter(oldSlice)
使用 sync.Pool 缓存临时对象减少 GC 压力
频繁创建销毁相同结构体（如 HTTP 请求中的 bytes.Buffer、自定义 parser 上下文）时，值拷贝本身不是问题，但伴随的堆分配会拖慢性能。这时应跳过“避免拷贝”思路，转向“复用内存”。
立即学习“go语言免费学习笔记（深入）”；
-
sync.Pool适合生命周期短、可重置的对象；不要存含 finalizer 或需严格释放资源的对象 - 从 pool 获取后必须调用重置方法（如
buf.Reset()），否则残留数据会导致 bug - pool 不保证一定命中，始终要处理
nil情况：
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
func handleRequest() {
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // 必须重置
// ... use buf
bufPool.Put(buf)
}
编译器逃逸分析比你更懂什么时候该堆分配
别凭直觉加 *。用 go build -gcflags="-m" main.go 查看变量是否逃逸。如果一个结构体在函数内创建、未取地址、未传给全局变量或 goroutine，它大概率留在栈上——此时值传参开销极小，指针反而多一次解引用。
- 常见逃逸原因：传入接口（
fmt.Println(s)）、闭包捕获、goroutine 中使用、返回局部变量地址 - 当
-m输出显示... escapes to heap，再考虑用指针或预分配 - 过度规避拷贝可能让代码更难读、更易出错（如 nil 指针 panic），优先保障正确性，再优化
最常被忽略的一点：不是所有“拷贝”都值得优化。先用 pprof 定位真实热点，确认 runtime.mallocgc 或内存分配次数是瓶颈，再动手。否则你省下的几纳秒，可能被一次没测过的并发 bug 抵消掉。
