刚从其他语言转到Go的开发者，几乎都踩过这样一个坑：在函数里修改了传入的int变量或者结构体字段，结果函数执行完，外面的变量纹丝不动。这不是bug，而是Go语言函数传参机制决定的——所有参数都是值传递。理解这一点并掌握正确的修改方式，是写好Go代码绕不开的一课。这篇文章会把值类型修改的原理和实践方案讲透，配上可直接运行的代码示例，看完你就能彻底搞明白。
为什么函数内改不动外部变量：值拷贝的本质
Go语言规定，函数调用时传给形参的永远是实参的一个副本。这句话听起来简单，但含义值得细品。比如你传一个int，形参拿到的是这个数值的拷贝；传一个结构体，整个结构体的内容都会被复制一份。函数内部对副本做的任何修改，都只作用在这份拷贝上，函数返回后副本被丢弃，原始变量毫发无损。
我们可以用一段代码验证这个行为。下面定义一个函数试图修改传入的int，结果会发现外部变量完全没变：
package main
import "fmt"
func tryChange(n int) {
n = 100
fmt.Println("函数内部 n =", n) // 输出 100
}
func main() {
x := 10
tryChange(x)
fmt.Println("函数外部 x =", x) // 输出 10，没有被修改
}
从内存角度看，x和n是两块独立的内存空间。调用tryChange(x)时，Go把x的值10复制到n的内存里，之后n=100只是改写了n那块内存，与x没有任何关系。这也解释了为什么slice、map、channel看起来“传引用”——其实它们传递的是底层数据结构的指针副本，所以通过副本能操作同一份底层数据，但如果你直接给slice形参整体赋值一个新的slice，外部同样感知不到。
方法一：传递指针，最直接的修改方案
既然传值是拷贝，那把变量的地址传进去就行了。指针本身也是一个值，但这个值存的是目标变量的内存地址。函数拿到地址后，通过解引用操作*p就能定位并修改原始变量。这是Go中最标准、最常用的做法：
package main
import "fmt"
func realChange(n *int) {
*n = 100
}
func main() {
x := 10
realChange(&x) // 取地址传入
fmt.Println(x) // 输出 100，修改成功
}
结构体的修改同理，而且结构体场景下指针的优势更明显。一方面，传指针只复制一个地址（8字节左右），而传值要复制整个结构体的所有字段，结构体很大时拷贝开销不容忽视；另一方面，很多标准库和框架的约定就是接收指针接收者，保持一致性也更方便。
package main
import "fmt"
type User struct {
Name string
Age int
}
func growUp(u *User) {
u.Age++
}
func main() {
user := User{Name: "张三", Age: 25}
growUp(&user)
fmt.Println(user.Age) // 输出 26
}
需要提醒的是，使用指针传参时务必做好nil检查。如果调用方传了nil，函数内直接解引用会引发panic。稳妥的写法是在函数开头判断if u == nil { return }，尤其是写公共库代码时，这种防御性判断能避免不少线上事故。
方法二：结构体方法配合指针接收者
如果修改逻辑本来就属于某个类型，更优雅的方式是把它封装成方法，并使用指针接收者。Go的方法本质上是带接收者参数的函数，指针接收者等价于把*User作为第一个参数传入，效果和上面手动传指针完全一致：
package main
import "fmt"
type Counter struct {
count int
}
// 指针接收者，修改的是原始实例
func (c *Counter) Increment() {
c.count++
}
// 值接收者，修改的是副本，外部无感知
func (c Counter) WrongIncrement() {
c.count++
}
func main() {
c := &Counter{}
c.Increment()
c.Increment()
c.WrongIncrement() // 这次修改无效
fmt.Println(c.count) // 输出 2
}
一个常见的困惑是：Counter这个例子里面，c调用值接收者方法时Go会自动解引用，Counter调用指针方法时Go会自动取地址，看起来很智能。但这套语法糖有时会失效，比如类型是接口时、或者map中存储的值无法寻址时，编译器就不会帮你自动取地址了。所以选接收者类型时要考虑清楚：需要修改实例状态、或结构体较大时用指针接收者；小型不可变的数据用值接收者。同一个类型的方法，最好统一接收者类型，混用容易埋坑。
方法三：返回新值重新赋值
除了传指针，Go社区还推崇另一种思路：函数不去修改外部状态，而是把计算结果返回，由调用方自己决定是否覆盖原变量。这种函数式风格让数据流向更清晰，也天然避免了并发修改的问题：
package main
import "fmt"
func add(a, b int) int {
return a + b
}
func main() {
x := 10
x = add(x, 5) // 用返回值覆盖
fmt.Println(x) // 输出 15
}
这种方式看似“笨”，实际上非常符合Go的设计哲学——显式大于隐式。数据在哪里被修改一目了然，代码审查和调试时更容易追踪。多返回值特性还能顺便返回错误：result, err := compute(x)，这也是Go标准库里大量函数的标准形态。对于小型的值类型计算，优先考虑这种写法；只有当结构体很大、拷贝成本高，或者确实需要函数内原地修改时，再选择指针方案。
常见坑点与最佳实践总结
第一，注意slice的隐性陷阱。给slice传指针修改其元素其实不需要指针，因为slice头部含有指向底层数组的指针。但如果要在函数内执行append扩容并让外部看到新长度，就必须传*[]int。这是面试和实际开发中的高频错误点。
package main
import "fmt"
func appendItem(s []int) {
s = append(s, 99) // 可能触发扩容，修改的是局部副本的头部
}
func appendItemPtr(s *[]int) {
*s = append(*s, 99) // 外部可见
}
func main() {
a := []int{1, 2, 3}
appendItem(a)
fmt.Println(a) // [1 2 3]
appendItemPtr(&a)
fmt.Println(a) // [1 2 3 99]
}
第二，权衡拷贝成本与安全性。指针传递避免了大数据拷贝，但把修改权交给了函数，调用方必须清楚函数会不会改自己的数据。写文档注释时明确说明“此方法会修改接收者”是良好习惯。第三，并发场景下，多个goroutine通过指针修改同一个变量必须加锁或使用atomic包，否则会出现数据竞争，可以用go run -race检测。掌握这些细节后，无论是日常业务开发还是阅读标准库源码，你对Go数据传递的理解都会上一个台阶。