值类型传参必触发完整内存拷贝，开销与大小成正比；逃逸分析不影响拷贝行为；大结构体或大数组应优先考虑指针传递，尤其含 sync.Mutex 或高频调用场景。
值类型拷贝在函数传参时会触发完整内存复制
Go 中所有值类型（struct、[1024]int、string 等）在作为函数参数传递时，都会发生一次完整的内存拷贝。这不是引用传递，也不是“按需复制”，而是每次调用都无条件复制整个底层数据。
常见误判是认为 string 或 slice 是值类型所以“小”，但 string 底层包含 uintptr + int（共 16 字节），实际指向的底层数组不拷贝；而大 struct 或大数组（如 [8192]byte）会真实拷贝全部字节，开销直接与 size 成正比。
- 传入
func f(s [10000]int)：每次调用拷贝 10000×8 = 80KB - 传入
func f(u UserID)（含 5 个string字段）：只拷贝结构体头（通常 40–80 字节），不拷贝字符串底层数组 - 传入
func f(x MyBigStruct)（含嵌套[4096]byte字段）：整个 4KB 被复制，且无法被编译器逃逸分析优化掉
逃逸分析不能消除大值类型的拷贝开销
很多人混淆“变量是否逃逸”和“值是否被拷贝”。逃逸分析决定变量分配在栈还是堆，但不影响值类型传参时的拷贝行为。即使一个大 struct 完全在栈上分配，传给函数时仍会被复制一份。
可通过 go build -gcflags="-m -l" 观察，但注意输出中：
立即学习“go语言免费学习笔记（深入）”；
-
... moves to heap: ...表示逃逸，和拷贝无关 - 没有“避免拷贝”的提示 —— Go 编译器目前不会将大值类型自动转为指针传参
- 若函数内取了该参数的地址（如
&x），则该参数本身会逃逸，但拷贝已在调用前完成
type Big struct {
data [64<<10]byte // 64KB
}
func process(b Big) { // 这里 b 是完整拷贝
_ = &b // 此行导致 b 逃逸，但拷贝早已发生
}何时必须用指针替代值类型传参
不是所有值类型都要改指针，关键看成本是否可接受。经验阈值（在多数服务场景下）：
- 单个值 > 64 字节：优先考虑
*T - 结构体含任意数组字段（
[N]T，N > 8）：基本要改 - 结构体被高频调用（如 HTTP handler 内每请求调用多次）：哪怕 32 字节也值得评估
- 结构体字段含
sync.Mutex：必须用指针 —— 值拷贝会导致锁状态丢失，引发并发 bug
反例：把 type Point struct{ X, Y int } 改成 *Point 没必要；但 type ImageFrame struct{ Width, Height int; Pixels [1920*1080]byte } 不改就是性能热点。
benchmark 是唯一可信的判断依据
结构体大小只是粗略指标。真实影响取决于 CPU 缓存行填充、对齐、是否触发 TLB miss 等。必须用 go test -bench 验证：
func BenchmarkValueCopy(b *testing.B) {
v := Big{ /* 64KB 初始化 */ }
for i := 0; i < b.N; i++ {
consume(v) // 值传参
}
}
func BenchmarkPointerCopy(b *testing.B) {
v := &Big{ /* 同上 */ }
for i := 0; i < b.N; i++ {
consumePtr(v) // 指针传参
}
}实测中，64KB 值传参比指针慢 3–5 倍（取决于 CPU cache 和频率），但 128 字节可能只差 5%。没有测量就改，容易过早优化或遗漏真瓶颈。
特别注意：微基准测试要避免被编译器常量折叠或内联消除，建议用 goos=linux goarch=amd64 统一环境，并检查 -gcflags="-l" 关闭内联后再测。
