会，大对象传值会导致完整内存拷贝，引发显著性能开销；应优先传指针，小且不可变类型（≤16字节）可传值，需结合逃逸分析与基准测试验证。
大对象传值会导致内存拷贝吗
会，而且开销明显。Go 中所有参数都是值传递，struct、[1024]int、map[string]*HeavyStruct 这类大对象直接作为函数参数时，整个值（或其底层数据）会被完整复制。比如一个 1MB 的 struct，每次调用都触发一次 1MB 内存分配+拷贝，GC 压力和 CPU 时间都会陡增。
实操建议：
- 用
*T替代T：只要函数不需修改原对象的「所有权」或「生命周期」，传指针是最快路径 - 避免在循环内传大
struct：哪怕只读，也别让编译器被迫在栈上反复 copy 几百次 - 注意逃逸分析：
go tool compile -m看是否因传值导致本可栈分配的对象被抬升到堆——这会放大性能损耗
map/slice 传参为什么看起来不拷贝
因为它们本身是小结构体：slice 是 struct{ ptr *T; len, cap int }（24 字节），map 是 *hmap（8 字节指针）。传参时只复制这 24 或 8 字节，底层数据不会动。但要注意：这不等于「安全」——append 可能扩容并替换底层数组，map 写入可能触发 rehash，这些操作影响的是原始底层数组，不是拷贝副本。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 函数里
append(s, x)后原 slice 长度没变？那是你没接收返回值：s = append(s, x) - 函数里删了 map key，调用方看到变化？对，因为 map header 指向同一
hmap - 想「只读」却意外写入？加
copy()或用只读 wrapper 类型约束接口
什么时候该坚持传值而不是指针
小且不可变的类型，传值更高效、更安全。典型如 time.Time（24 字节）、net.IP（16 字节）、自定义的 type UserID int64。这些值小，栈上操作快，且无共享状态风险。
判断依据：
- 结构体大小 ≤ 机器字长×2（即 16 字节 on amd64）：通常优先传值
- 含
sync.Mutex或其他非拷贝字段：必须传指针，否则运行时报invalid operation: cannot assign to struct containing sync.Mutex field - 方法集需要指针接收者：如果已有
func (t *T) Do()，却传T，则无法调用该方法
逃逸分析不准时怎么验证真实开销
不能只信 -m 输出。实际性能要看基准测试 + 内存分配计数。比如：
func BenchmarkLargeStructByValue(b *testing.B) {
s := makeLargeStruct()
for i := 0; i < b.N; i++ {
consumeByValue(s) // 触发每次拷贝
}
}
func BenchmarkLargeStructByPtr(b *testing.B) {
s := makeLargeStruct()
for i := 0; i < b.N; i++ {
consumeByPtr(&s) // 零拷贝
}
}
运行 go test -bench=. -benchmem，对比 BenchmarkAllocs 和 ns/op。若值传递版本显示高 allocs/iter 且耗时翻倍，说明拷贝已成瓶颈。
容易被忽略的点：CGO 调用、反射、闭包捕获大对象，都可能隐式导致堆分配——这些不会出现在常规逃逸分析里，得靠 pprof heap profile 定位。
