Go中值类型赋值必复制内存，int、struct等按语义完整拷贝；大结构体（>128字节）应显式传指针；map/slice/channel赋值仅拷贝头信息；接口赋值会连同大值一起拷贝，需警惕性能开销。
值类型赋值时内存复制不可回避
Go语言中int、struct、[3]int等值类型在赋值、传参、返回时会完整拷贝底层数据。这不是优化选项，而是语言语义的一部分——你拿到的永远是独立副本。
常见错误现象：修改函数内struct字段后，调用方原变量未变化，误以为“传引用”；或对大结构体（如含[1024]byte字段）高频传参，CPU缓存压力陡增。
- 若结构体总大小 ≤ 机器字长（通常64位下≤8字节），拷贝开销极小，可放心按值传递
- 超过128字节建议显式传指针：
func process(&largeStruct)，避免无意间触发大量内存复制 - 编译器不会自动将大值类型转为指针——它严格遵循你写的类型签名
map/slice/channel不是值类型但表现像“引用”
map、slice、channel本身是值类型，但它们的底层数据结构（如hmap、sliceHeader）包含指针字段。因此赋值时只拷贝头信息（如指针、长度、容量），不拷贝底层数组或哈希桶。
这导致一个典型陷阱：对slice调用append可能引发底层数组扩容，此时新slice指向新地址，原slice仍指向旧数组——看似“共享”，实则行为取决于是否扩容。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖
slice赋值后的写共享：除非确认未扩容且操作同一子区间，否则结果不确定 -
map赋值后两个变量操作同一哈希表，但并发读写仍需加锁或使用sync.Map - 想真正隔离数据？用
copy(dst, src)或手动重建map/slice
接口值拷贝隐藏了底层数据的归属
当把一个值类型变量赋给接口（如interface{}），Go会把该值**连同其类型信息一起拷贝进接口的底层结构**。如果值本身很大（比如一个1MB的struct），这个拷贝就发生在接口创建时。
容易被忽略的性能点：频繁将大对象转为interface{}（如日志打点、反射调用、泛型约束边界检查），会反复触发内存分配和复制。
- 避免对大结构体直接传入
fmt.Printf("%v", hugeStruct)——改用指针&hugeStruct或自定义String()方法 - 接口变量自身是小结构（2个指针大小），但它的“数据字段”可能很大，这点在pprof里常表现为
runtime.convT2I高耗时 - 使用
go tool compile -gcflags="-S"可观察接口装箱是否引入额外MOVQ或CALL runtime.convT2I
结构体嵌套指针改变拷贝行为边界
结构体是否“轻量”不能只看字段数量，而要看所有字段（包括嵌套结构体）是否含指针或引用类型。一个含*bytes.Buffer字段的结构体，拷贝时只复制指针（8字节），但语义上它仍可能间接影响外部状态。
这使得“值类型安全”变得有条件：表面不可变，底层可能可变。
- 对外暴露结构体时，若含指针字段，需明确文档说明是否允许外部修改其指向内容
- 想彻底禁止外部副作用？在结构体字段上加
unexported字段+构造函数封装，或用sync.Once延迟初始化内部指针 - JSON序列化/反序列化时，
nil指针字段默认被忽略——这和值拷贝无关，但常与“我以为拷贝了整个对象”的错觉交织出现
值拷贝不是bug，是Go控制内存生命周期和并发安全的基石。问题往往出在开发者没意识到某个struct实际有几百字节，或误把slice的头拷贝当成深拷贝。真要排查，unsafe.Sizeof和pprof比猜更可靠。
