会，Go中所有值类型赋值均发生内存拷贝，语义保证独立副本；纯字段深拷贝，含引用字段仅拷贝header，底层数据共享，拷贝开销由unsafe.Sizeof决定。
会，Go 中所有值类型赋值（包括 =、函数传参、函数返回）都必然发生内存拷贝。这不是优化选项，而是语言语义保证：你拿到的永远是一个独立副本，修改它绝不会影响原变量——但“独立”只针对值本身，不自动延伸到底层共享资源。
值类型赋值时到底拷贝了什么
Go 的值类型包括 int、float64、[3]int、string、struct 等。赋值时，编译器会把整个值的内存块复制一份：
- 纯基础字段（如
int、bool、嵌套的纯 struct）→ 完整深拷贝，彻底隔离 - 含引用字段的 struct（如字段是
[]int、map[string]int、*bytes.Buffer）→ 仅拷贝 header（指针+长度+容量等），底层数据仍共享 - 拷贝开销 =
unsafe.Sizeof(T)，和字段是否“实际占用大内存”无关；一个含 1MB slice 的 struct，Sizeof可能只有 24 字节
函数返回值也逃不掉拷贝
哪怕函数只返回一个 Point 结构体，Go 也会在栈帧销毁前，把它的完整内容复制到调用方指定位置：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
type Point struct{ X, Y int }
func getOrigin() Point { return Point{0, 0} }
p1 := getOrigin() // 这里发生了拷贝
p2 := p1 // 再次拷贝
p2.X = 99 // p1.X 仍是 0
- 编译器可能用 RVO（返回值优化）减少中间临时对象，但语义上仍是“返回副本”，不是“返回原地址”
- 如果 struct 很大（比如含 megabytes 级别字段），频繁返回值类型会带来明显性能损耗
- 此时应改用
*Point返回指针，避免拷贝——但要同步考虑生命周期和逃逸分析
切片元素是值类型？小心“假隔离”
切片本身是引用类型（header 是值类型），但它的元素可以是值类型。这时容易误判数据归属：
立即学习“go语言免费学习笔记（深入）”；
data := []int{1, 2, 3}
item := data[0] // item 是 int，拷贝成功：修改 item 不影响 data[0]
data[0] = 99 // 但这是对底层数组的写入，会影响所有共享该数组的 slice
- 对
data[i]赋值 → 修改底层数组，不是拷贝行为 - 想真正隔离元素修改？要么用指针切片
[]*int，要么显式复制整个切片：copy(dst, src)或append([]int(nil), src...) - 不确定是否共享？打印地址：
fmt.Printf("%p", &data[0])对比不同 slice 的首元素地址
真正难缠的从来不是“会不会拷贝”，而是“拷贝了什么”。一个 struct 看似简单，只要它字段里藏着 map 或 chan，你就得自己决定：是要浅拷贝（快但共享）、还是手动深拷贝（安全但费劲）、或者干脆用指针控制所有权。
