Go语言从设计之初就坚持了一个简单粗暴的原则：一切传值。无论是函数参数还是返回值，传递的都是值的拷贝。这个设计让语义变得非常清晰——调用方拿到的返回值和被调用方内部的变量互不干扰，但同时也带来了一连串值得深究的问题：结构体返回时拷贝了什么？拷贝发生在栈上还是堆上？什么时候应该改用指针返回？本文将从底层机制入手，把这些问题逐一讲透。
值类型返回的底层机制：一次完整的内存拷贝
先看一个最基础的例子。假设我们定义一个Point结构体，并通过函数返回它：
package main
import "fmt"
type Point struct {
X, Y int
}
func makePoint(x, y int) Point {
p := Point{X: x, Y: y}
return p
}
func main() {
p := makePoint(1, 2)
fmt.Println(p.X, p.Y)
}在这个例子中，return p执行时，Go运行时会计算Point的大小（两个int，在64位平台上是16字节），然后把p的内容逐字节拷贝到为返回值预留的内存空间中。调用方拿到的是一份全新的副本，之后无论调用方如何修改这个返回值，都不会影响函数内部那个已经随着栈帧销毁的p。
需要特别注意的是，拷贝的深度由类型本身决定。如果结构体里嵌入了数组，比如type Buffer struct { data [4096]byte }，那么返回这个结构体时整个4096字节的数组都会被复制一遍。但如果字段是切片、map或指针这类引用类型，拷贝的只是头部结构（切片是24字节的指针、长度、容量三元组），底层数组是共享的。这就引出一个隐蔽的坑：值返回并不能保证“深隔离”，引用字段背后的数据仍然是共享的。
在汇编层面，值返回的实现方式有两种：较小的返回值会通过寄存器传递（Go 1.17及以后的寄存器调用约定），较大的返回值则由调用方在栈上预先分配好空间，再把地址隐式传给被调用方，由被调用方把数据写进去。理解这一点对后面的性能分析很有帮助——小结构体的值返回实际上开销非常小。
值返回与指针返回的对比：如何选择
指针返回是绕开拷贝的常见手段。把上面的函数改成返回*Point，返回的就只是一个8字节的地址。很多初学者因此形成一种直觉：指针总是更快。这个直觉在多数情况下是对的，但并非绝对。
// 值返回：拷贝整个结构体
func makePointValue(x, y int) Point {
return Point{X: x, Y: y}
}
// 指针返回：只传递地址，但对象通常逃逸到堆上
func makePointPtr(x, y int) *Point {
p := &Point{X: x, Y: y}
return p
}两者真正的差异不只是拷贝成本。返回指针意味着这个对象必须“活过”函数的栈帧，Go编译器的逃逸分析会把它分配到堆上，于是产生了额外的堆分配开销、潜在的GC压力，以及间接访问带来的缓存不友好。而值返回的对象可以完全留在栈上，函数返回即销毁，零GC负担。对于几十字节以内的小结构体，值返回往往比指针返回更快，这在标准库中有大量体现——time.Time、netip.Addr等类型都刻意设计成值语义并按值返回。
一个实用的经验法则：结构体小于64字节且不含大数组，优先值返回；结构体很大、包含互斥锁（sync.Mutex等不可拷贝类型）、或者需要在多处共享同一份可变状态时，用指针返回。另外要留意方法接收者的选择——如果类型的方法接收者都是指针，那么返回指针能保持一致性，避免出现“值上调用指针方法导致原对象未被修改”的经典错误。
用逃逸分析看清返回值的真实去向
猜测不如验证。Go提供了内置的逃逸分析工具，执行go build -gcflags="-m"就能看到编译器对每个变量的分配决策。针对上面的两个函数，输出大致如下：
// 命令：go build -gcflags="-m" ./main.go
//
// 输出示例：
// ./main.go:10:9: &Point{...} escapes to heap
// ./main.go:9:2: moved to heap: p
// ./main.go:8:13: makePointPtr does not escapeescapes to heap明确告诉我们makePointPtr中的对象被分配到了堆上，而makePointValue则完全没有逃逸相关的提示，说明返回值留在了栈上。再加一个细节：fmt.Println这类接收interface{}参数的函数会导致参数逃逸到堆上，所以做基准测试时要避免混入打印语句，否则测出来的数据不能反映真实情况。
配合基准测试效果更好。用go test -bench=. -benchmem对比两种实现的单次操作耗时和堆分配次数，如果指针版本每次调用都产生一次allocs/op，而值版本是0，差距一目了然。值得注意的是，逃逸分析的结果受编译器版本和上下文影响，比如把返回值限制在局部变量、不存入interface、不被闭包捕获，编译器就更倾向于栈分配。因此优化前先跑分析，避免凭感觉改代码。
典型场景的实践建议与常见坑
大结构体的返回策略
当结构体达到KB级别时，值返回的拷贝成本开始显现，但也不必立刻转向指针。可以考虑把数据改为切片或指针字段，让结构体本身保持小巧；或者重构API，让调用方传入一个指针由函数填充（func fill(p *BigStruct)），这在解析器、解码器类库中很常见，标准库的io.Reader相关实现就大量采用这种模式。
命名返回值的语义细节
func divide(a, b int) (result int, err error) {
if b == 0 {
err = fmt.Errorf("除数不能为零")
return // 裸返回，返回当前的 result 和 err
}
result = a / b
return
}命名返回值在定义时就会被初始化为零值，裸返回时返回的就是这些变量的当前值。要注意defer闭包中修改命名返回值会直接改变函数的实际返回结果，这既是实现recover捕获错误的标准手法，也是容易埋bug的地方。
不可拷贝类型坚决用指针
包含sync.Mutex、sync.WaitGroup、文件描述符包装等字段的结构体，拷贝后会导致锁失效或资源重复释放。虽然可以用go vet的copylocks检查捕获大部分问题，但从设计上让这类类型只通过指针使用，是更稳妥的约定。
总结一下：Go的值返回机制本质是一次语义明确的拷贝，小对象留在栈上性能极佳，大对象或共享状态才需要指针。掌握逃逸分析和基准测试这两个工具，在写代码时就能对每一次return的开销心中有数，而不是依赖道听途说的优化口诀。