是的，Go函数返回值为非指针值类型时一定会拷贝，包括int或struct等，编译器保证在栈帧销毁前将完整副本复制到调用方指定内存位置，即使通过RVO优化延迟或减少中间拷贝，语义上仍是独立副本。
Go 函数返回值是值类型时一定会拷贝吗
是的，只要返回的是非指针的值类型（比如 int、struct{}、[3]int），Go 编译器在返回时会执行一次完整的内存拷贝。这不是“可能”，而是语言规范层面的保证：函数调用栈帧销毁前，返回值必须被复制到调用方指定的内存位置（可能是栈上变量，也可能是临时匿名位置）。
但要注意：编译器可能通过逃逸分析和返回值优化（Return Value Optimization, RVO 类似机制，Go 中叫“return value copy elision”）把拷贝延迟到更合适的位置，甚至消除部分中间拷贝——但这不改变语义：对调用者而言，拿到的永远是一个独立副本。
struct 返回值的拷贝开销怎么看
结构体越大，拷贝成本越高。尤其当它包含大数组、嵌套结构或大量字段时，return myBigStruct 会触发整块内存的复制（字节级 memcpy）。这不是引用传递，也没有隐式优化。
- 小 struct（如
struct{ x, y int }）：通常就 16 字节，拷贝几乎无感 - 中等 struct（如含
[1024]byte）：每次返回都复制 1KB，高频调用下可观 - 大 struct（如含
[100000]int）：直接导致性能毛刺，GC 压力也可能上升
验证方式：用 go build -gcflags="-m" main.go 查看逃逸分析输出，若出现 ... escapes to heap，说明该 struct 被分配到了堆上，但返回时仍需从堆复制一份给调用方——此时拷贝发生在堆内存之间，反而更慢。
立即学习“go语言免费学习笔记（深入）”；
如何避免不必要的 struct 拷贝
核心思路是让调用方决定是否需要副本，而不是函数强制返回副本。常见做法有：
- 返回指针：
func NewConfig() *Config—— 避免拷贝，但需注意生命周期和并发安全 - 接受输出参数：
func FillConfig(dst *Config) error—— 复用已有内存，零分配 - 用 sync.Pool 缓存临时 struct 实例，减少 GC 和重复分配
- 对只读场景，可考虑返回
interface{}或自定义只读 wrapper，内部仍持指针
注意：不要盲目加 *T。如果 struct 本身很小，或者函数本就只调用一两次，加指针反而引入解引用开销和 GC 跟踪成本。
切片、map、channel 返回值的“假拷贝”现象
它们是引用类型，但底层 header 是值类型。所以 return []int{1,2,3} 确实会拷贝 slice header（3 个 word：ptr, len, cap），但不会拷贝底层数组。这常被误认为“没拷贝”，其实 header 拷贝依然发生，只是代价小。
典型陷阱：
func bad() []int {
s := make([]int, 1000)
// ... fill s
return s // header 拷贝，但底层数组未复制，调用方拿到的是同一块内存
}
这段代码没问题；但如果返回的是局部数组转成的切片：
func dangerous() []int {
arr := [1000]int{}
return arr[:] // ❌ arr 是栈变量，返回后栈帧销毁，切片指向已释放内存！
}
这种写法在运行时可能 panic 或读到脏数据，因为 header 虽然拷贝了，但 ptr 指向的已是无效栈地址。
最易被忽略的一点：哪怕你只返回一个 int，它也是拷贝；而一个 1MB 的 struct 返回，拷贝动作同样发生——Go 不会因类型大小自动切换为指针语义。是否拷贝，只取决于你写的是 T 还是 *T。
