在Go语言里，结构体的赋值行为经常让从其他语言转过来的开发者感到困惑。明明只是把一个结构体赋值给另一个变量，修改副本之后，原结构体里的切片内容也跟着变了。这背后的原因就在于：Go的结构体赋值是浅拷贝，只复制字段的值本身，遇到引用类型时复制的是指针或头部结构，底层数据依然是共享的。本文就来把这个机制彻底讲透，并给出几种可靠的深拷贝实现方案。
一、Go结构体赋值的底层机制：浅拷贝是怎么发生的
首先要明确一点，Go是彻头彻尾的值传递语言。当你执行b := a这样的结构体赋值时，编译器会把这个结构体所占用的内存完整复制一份。对于只包含基本类型字段（int、string、bool等）的结构体来说，这种复制就是完全独立的，修改副本不会影响原值。
但问题出在引用类型字段上。Go中的slice本质上是一个包含指针、长度、容量三个字段的结构头；map本身就是一个指针；指针类型更是直接存地址。当结构体包含这些字段时，赋值只复制了这个头结构，副本和原值指向同一块底层数据。看下面这个例子：
type User struct {
Name string
Scores []int
Profile map[string]string
}
func main() {
a := User{
Name: "张三",
Scores: []int{90, 85, 77},
Profile: map[string]string{"city": "北京"},
}
b := a // 浅拷贝
b.Scores[0] = 100
b.Profile["city"] = "上海"
fmt.Println(a.Scores[0]) // 输出100，原数据被改了
fmt.Println(a.Profile["city"]) // 输出上海
}
从内存角度看，赋值之后栈上确实存在两份独立的User结构，其中Name字符串的底层数据也是各自独立的（字符串头会被复制，且字符串本身不可变）。但Scores的底层数组、Profile的哈希表，都只有一份，两个结构体的字段指向同一片堆内存。这就是所谓的浅拷贝：复制了外壳，共享了内核。
还需要注意一个容易被忽视的点：string虽然是引用语义的头部结构，但由于字符串内容不可变，浅拷贝它通常不会引发问题。真正需要警惕的是slice、map、channel、指针，以及嵌套了这些类型的子结构体。
二、手动实现深拷贝：自定义Copy方法的正确姿势
最直接也最可控的方式是为结构体定义一个显式的复制方法，在方法内部对每个引用类型字段重新分配内存并逐个复制数据。这种方式的优点是性能好、逻辑清晰、不依赖反射，缺点是字段变更时需要同步维护复制代码。
type User struct {
Name string
Scores []int
Profile map[string]string
Friends *[]string
}
// DeepCopy 返回一个完全独立的副本
func (u *User) DeepCopy() *User {
if u == nil {
return nil
}
clone := new(User)
clone.Name = u.Name // string本身不可变，直接赋值即可
// 切片：重新分配底层数组并复制
clone.Scores = make([]int, len(u.Scores))
copy(clone.Scores, u.Scores)
// map：重建哈希表逐个赋值
clone.Profile = make(map[string]string, len(u.Profile))
for k, v := range u.Profile {
clone.Profile[k] = v
}
// 指针字段：判断nil后重新分配
if u.Friends != nil {
friends := make([]string, len(*u.Friends))
copy(friends, *u.Friends)
clone.Friends = &friends
}
return clone
}
这里有几个细节值得强调。第一，所有make都显式传入了容量，避免复制过程中触发扩容带来的额外开销。第二，指针字段必须先判空，直接对nil指针解引用会直接panic。第三，如果结构体嵌套了子结构体，且子结构体也含引用字段，必须对子结构体同样调用其DeepCopy方法，否则嵌套层级依然是浅拷贝。
在实际工程中，建议把DeepCopy方法放在类型定义旁边，并配套写单元测试，用reflect.DeepEqual验证副本内容一致，再用reflect.ValueOf(x).Pointer()验证底层数据地址确实不同。这样能在字段重构时第一时间发现遗漏。
三、通用方案：利用序列化和反射实现自动化深拷贝
当结构体层级很深、字段很多时，手动维护复制代码既繁琐又容易出错。这时可以考虑两种自动化方案。
第一种是基于序列化。把结构体编码成字节流再解码回来，天然得到一份全新的数据。最常见的是JSON方式：
import "encoding/json"
func CopyByJSON[T any](src T) (T, error) {
var dst T
data, err := json.Marshal(src)
if err != nil {
return dst, err
}
err = json.Unmarshal(data, &dst)
return dst, err
}
这个方案写起来最省事，但局限也不少：无法处理未导出字段，遇到func、chan、复杂指针关系时会丢数据或报错，而且性能比手动复制低一个数量级。它只适合对性能不敏感、字段全部导出的场景，比如配置对象的快照。相比之下，gob编码能保留更多类型信息，但同样有速度开销。
第二种是封装反射做通用深拷贝。思路是递归遍历结构体的每个字段，遇到指针、切片、map就重新分配并逐元素递归复制：
import (
"reflect"
)
func DeepClone(src interface{}) interface{} {
if src == nil {
return nil
}
v := reflect.ValueOf(src)
return deepCopyValue(v).Interface()
}
func deepCopyValue(v reflect.Value) reflect.Value {
switch v.Kind() {
case reflect.Ptr:
if v.IsNil() {
return v
}
// 创建新指针，递归复制指向的值
p := reflect.New(v.Type().Elem())
p.Elem().Set(deepCopyValue(v.Elem()))
return p
case reflect.Slice:
if v.IsNil() {
return v
}
s := reflect.MakeSlice(v.Type(), v.Len(), v.Len())
for i := 0; i < v.Len(); i++ {
s.Index(i).Set(deepCopyValue(v.Index(i)))
}
return s
case reflect.Map:
if v.IsNil() {
return v
}
m := reflect.MakeMap(v.Type())
iter := v.MapRange()
for iter.Next() {
m.SetMapIndex(deepCopyValue(iter.Key()), deepCopyValue(iter.Value()))
}
return m
default:
return v
}
}
反射方案通用性最强，能处理任意嵌套层级，但性能开销介于手动复制和JSON之间，且同样拿不到未导出字段。另外要警惕循环引用，比如两个结构体互相持有指针，上面的递归实现会栈溢出，健壮的实现需要维护一个已访问地址的映射表来判断环。
四、方案对比与选型建议
三种方案各有取舍，简单对比如下：
| 方案 | 性能 | 通用性 | 主要限制 |
|---|---|---|---|
| 自定义Copy方法 | 最高 | 低，按类型编写 | 字段变更需同步维护 |
| 反射递归复制 | 中等 | 高，任意嵌套 | 无法处理未导出字段，需防循环引用 |
| JSON/gob序列化 | 最低 | 较高 | 丢字段类型信息，不支持func、chan |
选型时可以遵循这样的原则：核心业务对象、高频调用的复制逻辑，优先手写DeepCopy方法，把性能和正确性都掌握在自己手里；工具库、泛型容器这类需要处理未知类型的场合，用反射封装通用函数；而一次性的低频操作，比如测试夹具准备、配置回滚，直接走序列化最省心。
最后补充一个工程实践建议：与其到处补深拷贝，不如从设计上减少可变共享状态。Go官方并没有提供内置的深拷贝原语，很大程度上是希望开发者显式思考数据的所有权。如果结构体中的引用字段确实需要隔离修改，用值接收者方法配合不可变数据风格，或者干脆定义只读接口，往往比复制本身更干净。理解了浅拷贝的成因，深拷贝就只是一个机械但必须认真对待的实现细节。