本文由云 + 社区发表
导言
几乎每一个 C ++ 开发人员，都被面试过有关于函数参数是值传递还是引用传递的问题，其实不止于 C ++，任何一个语言中，我们都需要关心函数在参数传递时的行为。在 golang 中存在着 map、channel 和 slice 这三种内建数据类型，它们极大的方便着我们的日常 coding。然而，当这三种数据结构作为参数传递的时的行为是如何呢？本文将从这三个内建结构展开，来介绍 golang 中参数传递的一些细节问题。
背景
首先，我们直接的来看一个简短的示例，下面几段代码的输出是什么呢？
//demo1
package main
import “fmt”
func test_string(s string){
fmt.Printf(“inner: %v, %v\n”,s, &s)
s = “b”
fmt.Printf(“inner: %v, %v\n”,s, &s)
}
func main() {
s := “a”
fmt.Printf(“outer: %v, %v\n”,s, &s)
test_string(s)
fmt.Printf(“outer: %v, %v\n”,s, &s)
}
上文的代码段，尝试在函数 test_string() 内部修改一个字符串的数值，通过运行结果，我们可以清楚的看到函数 test_string() 中入参的指针地址发生了变化，且函数外部变量未被内部的修改所影响。因此，很直接的一个结论呼之欲出：golang 中函数的参数传递采用的是：值传递。
//output
outer: a, 0x40e128
inner: a, 0x40e140
inner: b, 0x40e140
outer: a, 0x40e128
那么是不是到这儿就回答完，本文就结束了呢？当然不是，请再请看看下面的例子：当我们使用的参数不再是 string，而改为 map 类型传入时，输出结果又是什么呢？
//demo2
package main
import “fmt”
func test_map(m map[string]string){
fmt.Printf(“inner: %v, %p\n”,m, m)
m[“a”]=”11″
fmt.Printf(“inner: %v, %p\n”,m, m)
}
func main() {
m := map[string]string{
“a”:”1″,
“b”:”2″,
“c”:”3″,
}
fmt.Printf(“outer: %v, %p\n”,m, m)
test_map(m)
fmt.Printf(“outer: %v, %p\n”,m, m)
}
根据我们前文得出的结论，按照值传递的特性，我们毫无疑问的猜想：函数外两次输出的结果应该是相同的，同时地址应该不同。然而，事实却正是相反：
//output
outer: map[a:1 b:2 c:3], 0x442260
inner: map[a:1 b:2 c:3], 0x442260
inner: map[a:11 b:2 c:3], 0x442260
outer: map[b:2 c:3 a:11], 0x442260
没错，在函数 test_map() 中对 map 的修改再函数外部生效了，而且函数内外打印的 map 变量地址竟然一样。做技术开发的人都知道，在源代码世界中，如果地址一样，那就必然是同一个东西，也就是说：这俨然成为了一个引用传递的特性了。
两个示例代码的结果竟然截然相反，如果上述的内容让你产生了疑惑，并且你希望彻底的了解这过程中发生了什么。那么请阅读完下面的内容，跟随作者一起从源码透过现象看本质。本文接下来的内容，将对 golang 中的 map、channel 和 slice 三种内建数据结构在作为函数参数传递时的行为进行分析，从而完整的解析 golang 中函数传递的行为。
迷惑人心的 Map
Golang 中的 map，实际上就是一个 hashtable，在这儿我们不需要了解其详细的实现结构。回顾一下上文的例子我们首先通过 make() 函数（运算符:= 是 make() 的语法糖，相同的作用）初始化了一个 map 变量，然后将变量传递到 test_map() 中操作。
众所周知，在任何语言中，传递指针类型的参数才可以实现在函数内部直接修改内容，如果传递的是值本身的，会有一次拷贝发生（此时函数内外，该变量的地址会发生变化，通过第一个示例可以看出），因此，在函数内部的修改对原外部变量是无效的。但是，demo2 示例中的变量却完全没有拷贝发生的迹象，那么，我们是否可以大胆的猜测，通过 make() 函数创建出来的 map 变量会不会实际上是一个指针类型呢？这时候，我们便需要来看一下源代码了：
// makemap implements Go map creation for make(map[k]v, hint).
// If the compiler has determined that the map or the first bucket
// can be created on the stack, h and/or bucket may be non-nil.
// If h != nil, the map can be created directly in h.
// If h.buckets != nil, bucket pointed to can be used as the first bucket.
func makemap(t *maptype, hint int, h *hmap) *hmap {
if hint < 0 || hint > int(maxSliceCap(t.bucket.size)) {
hint = 0
}
…
上面是 golang 中的 make() 函数在 map 中通过 makemap() 函数来实现的代码段，可以看到，与我们猜测一致的是：makemap() 返回的是一个 hmap 类型的指针 hmap。也就是说：test_map(map) 实际上等同于 test_map(hmap)。因此，在 golang 中，当 map 作为形参时，虽然是值传递，但是由于 make() 返回的是一个指针类型，所以我们可以在函数哪修改 map 的数值并影响到函数外。
我们也可以通过一个不是很恰当的反例来证明这点：
//demo3
package main
import “fmt”
func test_map2(m map[string]string){
fmt.Printf(“inner: %v, %p\n”,m, m)
m = make(map[string]string, 0)
m[“a”]=”11″
fmt.Printf(“inner: %v, %p\n”,m, m)
}
func main() {
var m map[string]string// 未初始化
fmt.Printf(“outer: %v, %p\n”,m, m)
test_map2(m)
fmt.Printf(“outer: %v, %p\n”,m, m)
}
由于在函数 test_map2() 外仅仅对 map 变量 m 进行了声明而未初始化，在函数 test_map2() 中才对 map 进行了初始化和赋值操纵，这时候，我们看到对于 map 的更改便无法反馈到函数外了。
//output
outer: map[], 0x0
inner: map[], 0x0
inner: map[a:11], 0x442260
outer: map[], 0x0
跟风的 Channel
在介绍完 map 类型作为参数传递时的行为后，我们再来看看 golang 的特殊类型：channel 的行为。还是通过一段代码来来入手：
//demo4
package main
import “fmt”
func test_chan2(ch chan string){
fmt.Printf(“inner: %v, %v\n”,ch, len(ch))
ch<-“b”
fmt.Printf(“inner: %v, %v\n”,ch, len(ch))
}
func main() {
ch := make(chan string, 10)
ch<- “a”
fmt.Printf(“outer: %v, %v\n”,ch, len(ch))
test_chan2(ch)
fmt.Printf(“outer: %v, %v\n”,ch, len(ch))
}
结果如下，我们看到，在函数内往 channel 中塞入数值，在函数外可以看到 channel 的 size 发生了变化：
//output
outer: 0x436100, 1
inner: 0x436100, 1
inner: 0x436100, 2
outer: 0x436100, 2
在 golang 中，对于 channel 有着与 map 类似的结果，其 make() 函数实现源代码如下：
func makechan(t *chantype, size int) *hchan {
elem := t.elem
…
也就是 make() chan 的返回值为一个 hchan 类型的指针，因此当我们的业务代码在函数内对 channel 操作的同时，也会影响到函数外的数值。
与众不同的 Slice
对于 golang 中 slice 的行为，可以总结一句话：与众不同。首先，我们来看下 golang 中对于 slice 的 make 实现代码：
func makeslice(et *_type, len, cap int) slice {
…
我们发现，与 map 和 channel 不同的是，sclie 的 make 函数返回的是一个内建结构体类型 slice 的对象，而并非一个指针类型，其中内建 slice 的数据结构如下：
type slice struct {
array unsafe.Pointer
len int
cap int
}
也就是说，如果采用 slice 在 golang 中传递参数，在函数内对 slice 的操作是不应该影响到函数外的。那么，对于下面的这段示例代码，运行的结果又是什么呢？
//demo5
package main
import “fmt”
func main() {
sl := []string{
“a”,
“b”,
“c”,
}
fmt.Printf(“%v, %p\n”,sl, sl)
test_slice(sl)
fmt.Printf(“%v, %p\n”,sl, sl)
}
func test_slice(sl []string){
fmt.Printf(“%v, %p\n”,sl, sl)
sl[0] = “aa”
//sl = append(sl, “d”)
fmt.Printf(“%v, %p\n”,sl, sl)
}
通过运行结果，我们看到，在函数内部对 slice 中的第一个元素的数值修改成功的返回到了 test_slice() 函数外层！与此同时，通过打印地址，我们发现也显示了是同一个地址。到了这儿，似乎又一个奇怪的现象出现了：makeslice() 返回的是值类型，但是当该数值作为参数传递时，在函数内外的地址却未发生变化，俨然一副指针类型。
//output
[a b c], 0x442260
[a b c], 0x442260
[aa b c], 0x442260
[aa b c], 0x442260
这时候，我们还是回归源码，回顾一下上面列出的 golang 内部 slice 结构体的特点。没错，细心地读者可能已经发现，内部 slice 中的第一个元素用来存放数据的结构是个指针类型，一个指向了真正的存放数据的指针！因此，虽然指针拷贝了，但是指针所指向的地址却未更改，而我们在函数内部修改了指针所指向的地方的内容，从而实现了对元素修改的目的了。
让我们再进阶一下上面的示例，将注释的那行代码打开：
sl = append(sl, “d”)
再重新运行上面的代码，得到的结果又有了新的变化：
//output
[a b c], 0x442280
[a b c], 0x442280
[aa b c d], 0x442280
[aa b c], 0x442280
函数内我们修改了 slice 中一个已有元素，同时向 slice 中 append 了另一个元素，结果在函数外部：
修改的元素生效了；
append 的元素却消失了。
其实这就是由于 slice 的结构引起的了。我们都知道 slice 类型在 make() 的时候有个 len 和 cap 的可选参数，在上面的内部 slice 结构中第二和第三个成员变量就是代表着这俩个参数的含义。我们已知原因，数据部分由于是指针类型，这就决定了在函数内部对 slice 数据的修改是可以生效的，因为值传递进去的是指向数据的指针。而同一时刻，表示长度的 len 和容量的 cap 均为 int 类型，那么在传递到函数内部的就仅仅只是一个副本，因此在函数内部通过 append 修改了 len 的数值，但却影响不到函数外部 slice 的 len 变量，从而，append 的影响便无法在函数外部看到了。
解释到这儿，基本说清了 golang 中 map、channel 和 slice 在函数传递时的行为和原因了，但是，喜欢提问的读者可能一直觉得有哪儿是怪怪的，这个时候我们来完整的整理一下已经的关于 slice 的信息和行为：
makeslice() 出来的一定是个结构体对象，而不是指针；
函数内外打印的 slice 地址一致；
函数体内对 slice 中元素的修改在函数外部生效了；
函数体内对 slice 进行 append 操作在外部没有生效；
没错了，对于问题 1、3 和 4 我们应该都已经解释清楚了，但是，关于第 2 点为什么函数内外对于这三个内建类型变量的地址打印却是一致的？我们已经更加确定了 golang 中的参数传递的确是值类型，那么，造成这一现象的唯一可能就是出在打印函数 fmt.Printf() 中有些小操作了。因为我们是通过 %p 来打印地址信息的，为此，我们需要关注的是 fmt 包中 fmtPointer()：
func (p *pp) fmtPointer(value reflect.Value, verb rune) {
var u uintptr
switch value.Kind() {
case reflect.Chan, reflect.Func, reflect.Map, reflect.Ptr, reflect.Slice, reflect.UnsafePointer:
u = value.Pointer()
default:
p.badVerb(verb)
return
}
…
}
我们发现在 fmtPointer() 中，对于 map、channel 和 slice，都被当成了指针来处理，通过 Pointer() 函数获取对应的值的指针。我们知道 channel 和 map 是因为 make 函数返回的就已经是指针了，无可厚非，但是对于 slice 这个非指针，在 value.Pointer() 是如何处理的呢？
// If v’s Kind is Slice, the returned pointer is to the first
// element of the slice. If the slice is nil the returned value
// is 0. If the slice is empty but non-nil the return value is non-zero.
func (v Value) Pointer() uintptr {
// TODO: deprecate
k := v.kind()
switch k {
case Chan, Map, Ptr, UnsafePointer:
return uintptr(v.pointer())
case Func:
…
case Slice:
return (*SliceHeader)(v.ptr).Data
}
…
}
果不其然，在 Pointer() 函数中，对于 Slice 类型的数据，返回的一直是指向第一个元素的地址，所以我们通过 fmt.Printf() 中 %p 来打印 Slice 的地址，其实打印的结果是内部存储数组元素的首地址，这也就解释了问题 2 中为什么地址会一致的原因了。
总结
通过上述的一系列总结，我们可以很高兴的确定的是：在 golang 中的传参一定是值传递了！
然而 golang 隐藏了一些实现细节，在处理 map，channel 和 slice 等这些内置结构的数据时，其实处理的是一个指针类型的数据，也是因此，在函数内部可以修改（部分修改）数据的内容。
但是，这些修改得以实现的原因，是因为数据本身是个指针类型，而不是因为 golang 采用了引用传递，注意二者的区别哦～
此文已由作者授权腾讯云 + 社区在各渠道发布
获取更多新鲜技术干货，可以关注我们腾讯云技术社区 - 云加社区官方号及知乎机构号