函数调用时传进去的结构体，在函数内部改了半天，返回后原变量纹丝不动。这不是Go的设计缺陷，而是参数传递机制在起作用。Go语言中所有的参数——无论类型是int、string、结构体还是切片——都是以值拷贝的方式传入函数的。对于值类型，拷贝的就是数据本身；对于引用类型，拷贝的是那个包含指针和长度信息的头部结构。真正理解这个机制，需要从函数栈帧和内存布局开始。

函数调用时到底发生了什么

当一个Go函数被调用时，运行时会为它分配一块新的栈帧。调用方需要把实参的值放到被调用函数能够访问的位置。对于值类型参数，编译器会生成一段复制指令，把实参的内存内容原封不动地复制一份到新栈帧的参数区域。比如一个包含三个int字段的结构体，调用时就是把这12个字节（假设int占4字节）逐一拷贝过去。

代码示例可以直观展示这个过程：

type Point struct {
    X int
    Y int
}
func modify(p Point) {
    p.X = 100
    p.Y = 200
}
func main() {
    p := Point{X: 1, Y: 2}
    modify(p)
    fmt.Println(p.X, p.Y) // 输出: 1 2
}

函数modify接收到的p是实参p的一份完整复制。在函数内部修改p.X，只是修改了栈帧中那份副本的字段，main函数中的原始结构体根本没有被触及。这种机制简单、安全，代价就是每个值类型参数都要付出一次内存复制。如果结构体很大，这个复制成本会线性增长。

字符串虽然底层有指针，但作为参数传递时同样遵循值拷贝规则。string类型在Go内部是一个包含指向底层字节数组的指针和长度字段的结构体，传参时复制的是这个结构体本身，而不是字节数组。所以修改字符串变量重新赋值不会影响外部，但如果通过unsafe包强行修改底层字节，外部字符串仍然会受影响，因为底层数组是共享的。

值类型与引用类型的传参差异

很多开发者认为切片、映射和通道是引用传递，这是不准确的。它们的参数传递仍然是值拷贝，只是拷贝的内容里包含了指向底层数据结构的指针。以切片为例，Go的切片头部是一个包含指针、长度和容量的三元组。将这个切片作为参数传入函数时，复制的是这三个字段的值。函数内部对切片元素的修改会影响外部，因为两边切片头部的指针指向同一个底层数组。

func appendAndModify(s []int) {
    s[0] = 99
    s = append(s, 100)
}
func main() {
    s := []int{1, 2, 3}
    appendAndModify(s)
    fmt.Println(s) // 输出: [99 2 3]
}

上面代码中，s[0]的修改被外部看到了，但append后的新切片并没有影响外部长度。原因在于append可能触发底层数组重新分配，函数内部的s指向了新的数组，而外部的s仍然指向旧数组。这恰恰证明切片传参是值拷贝，而不是引用传递。真正的引用传递语义只有在使用指针时才能实现。

结构体越大，值拷贝的代价就越高。如果一个结构体包含一个长度为几千的数组，每次函数调用就会复制整个数组。此时应该考虑传递结构体指针。但指针也会带来逃逸到堆上的可能，降低缓存局部性。所以选择值还是指针，需要结合实际场景权衡，而不是无脑认为指针总是更快。

编译器如何优化参数拷贝

Go编译器在编译阶段会做很多优化来减少不必要的值拷贝。其中一项是函数内联，当函数体足够简单且调用频繁时，编译器会直接把函数体嵌入调用点，消除了参数传递和返回的栈帧开销，拷贝自然也就没有了。但内联也有副作用，比如增加二进制体积，调试时栈信息不完整。

逃逸分析是另一个重要工具。编译器会分析值类型参数是否在函数返回后仍被引用。如果没有，值就可以安全地分配在栈上，复制操作只是栈内几个字节的移动，成本极低。如果值逃逸到堆上，则不仅需要堆分配，还可能引入垃圾回收压力。对于大型结构体，即使没有逃逸，复制到栈上也可能消耗不少CPU周期，因为大块内存复制需要执行多条机器指令。

开发者可以通过基准测试来感受不同大小结构体的拷贝成本。下面是一个简单对比：

type small struct { a, b int }
type large struct { data [1024]int }
//go:noinline
func passSmall(s small) small { return s }
//go:noinline
func passLarge(l large) large { return l }
func BenchmarkSmall(b *testing.B) {
    s := small{a: 1, b: 2}
    for i := 0; i < b.N; i++ {
        s = passSmall(s)
    }
}
func BenchmarkLarge(b *testing.B) {
    l := large{}
    for i := 0; i < b.N; i++ {
        l = passLarge(l)
    }
}

运行基准测试可以看到，large结构体的拷贝时间大约是small的数百倍。这种差距在高频调用场景下会被急剧放大。因此，对于大于一定阈值（通常经验值是几十字节以上）的结构体，传递指针是更合理的选择。同时，传递指针时需要留意并发场景下的数据竞争问题，值拷贝天然提供了数据隔离。

常见误区与避坑建议

第一个误区是认为函数内修改slice的元素后外部一定能看到。正如前面演示的，如果函数内对slice进行了append而且触发了扩容，外部的slice长度和容量都不会改变，甚至后续再访问元素可能读到旧数据。正确做法是让函数返回新的slice，或者传入指向slice的指针，在函数内通过指针修改头部字段。

第二个误区是把map当成普通的引用类型，认为map传参不需要考虑nil情况。map类型的零值是nil，如果直接对nil map写入会panic。函数接收一个map参数时，接收到的是一份包含底层哈希表指针的头部复制。如果传入nil，函数内无法通过简单的赋值让外部map变成非nil，必须返回新map或者传入指针。

第三个误区是误以为interface参数可以避免拷贝。interface内部是一个类型信息和数据指针的组合，传参时依然要复制这个组合结构。如果interface底层持有的是大型值类型，复制interface只是复制指针，不会复制数据本身，但将值类型赋值给interface时，会发生一次装箱，装箱过程本身可能涉及堆分配和值拷贝。所以interface并不能绕过拷贝机制。

理解Go值类型参数拷贝的本质，能帮助开发者写出性能更好、行为更可预测的代码。在接口设计时，明确区分函数是否会修改入参，对于不会修改的值类型可以安全地按值传递；对于需要修改或者大型的数据，使用指针并注明调用方可共享内存。这样团队协作时就能减少很多关于“为什么改了没生效”的困惑。