在Go语言里，变量赋值和函数传参时的数据传递方式，直接决定了我们修改一个变量会不会影响到另一个变量。很多刚接触Go的人会把所有赋值都当成引用操作，结果在调试时发现某个看似无关的变量值突然变了。要彻底弄明白这件事，得从Go的值类型本质说起，看看内存层面到底发生了什么。
值类型赋值的底层机制
Go中的值类型包括基本类型（如int、string、bool、float64）、数组以及结构体。当我们写下a := b这种赋值语句时，如果b是值类型，编译器会为a分配一块新的内存，并把b当前存储的数据逐字节复制过去。此后a和b在内存中是完全独立的两个实体，修改a不会影响b，反之亦然。
这种拷贝发生在栈上还是堆上，由逃逸分析决定，但无论分配在哪里，语义上都是深拷贝表层数据。我们可以用一段简单代码验证：定义一个整型变量并赋值给另一个变量，分别打印地址观察。
package main
import "fmt"
func main() {
var x int = 10
y := x
y = 20
fmt.Println("x=", x, "addr=", &x) // x仍是10
fmt.Println("y=", y, "addr=", &y) // y是20，地址不同
}
从输出可以看到，x和y的地址不一样，且改y后x没变。这就是典型的值拷贝带来的隔离性。在写工具函数时，如果参数是值类型，函数内修改形参不会污染调用方的原值，这让代码推理更简单，但也可能因频繁拷贝大结构体带来性能开销。
结构体与数组中的浅拷贝陷阱
虽然结构体本身是值类型，但如果结构体字段里包含指针、切片、映射或通道，赋值拷贝就只复制了这些字段的表层描述符，没有复制它们指向的底层数据。比如一个结构体有Data []int字段，两个结构体变量赋值后，它们的Data切片头（包含指向底层数组的指针、长度、容量）被复制，但底层数组是同一块。修改其中一个切片的元素，另一个也能看到。
下面这个例子展示了结构体赋值后共享底层数组的情况。很多人误以为结构体赋值是完全隔离的，结果在配置克隆、请求上下文传递时踩坑。
package main
import "fmt"
type Config struct {
Name string
Tags []string
}
func main() {
c1 := Config{Name: "base", Tags: []string{"a", "b"}}
c2 := c1 // 值拷贝，但Tags底层数组共享
c2.Tags[0] = "z"
fmt.Println(c1.Tags[0]) // 输出z，c1被意外修改
fmt.Println(c2.Tags[0]) // 输出z
}
要避免这种意外数据变化，需要在赋值时手动做深拷贝：对切片重新make并复制元素，对映射同样遍历赋值，或者利用encoding/gob等序列化方案。如果结构体设计上希望被安全复制，应尽量使用值类型字段，或将共享引用字段的写操作通过方法控制，避免外部直接改底层。
函数传参时的拷贝与性能权衡
Go函数调用一律是值传递，也就是说实参会被拷贝一份传给形参。对于小的int或bool，这毫无问题；但对于大的数组或结构体，每次调用都全量拷贝可能很慢。此时常见做法是传指针，指针本身是值类型，拷贝的是地址，函数内通过地址改数据会影响原值，这就引入了另一类“意外变化”风险。
对比传值与传指针的写法能看清差异。传指针节省拷贝成本，但调用方必须知道函数可能修改原数据；传值安全但耗性能。实际工程中，超过两三个机器字的结构体通常传指针，同时用文档或命名约定表明会修改接收者。
package main
import "fmt"
type Big struct {
buf [1024]byte
}
func byVal(b Big) {
b.buf[0] = 1 // 不影响原值
}
func byPtr(b *Big) {
b.buf[0] = 1 // 修改原值
}
func main() {
var a Big
byVal(a)
fmt.Println(a.buf[0]) // 0
byPtr(&a)
fmt.Println(a.buf[0]) // 1
}
理解值类型赋值与拷贝，核心是先判断类型是否纯值、是否内嵌引用。在并发场景下，多个goroutine持有同一份底层数组的切片副本，更易出现竞态。建议在涉及共享数据时，明确用copy函数分离底层数组，或用sync.Mutex保护，从机制上杜绝意外数据变化。