Go 切片使用绕坑指南

在Go中按值传递时，为什么有时会更改切片？

不知道大家有没有发现在一个函数内部对切片参数进行了排序后也会改变函数外部原来的切片中元素的顺序，但是在函数内向切片增加了元素后在函数外的原切片却没有新增元素，更奇怪的是添加并排序后，外部的切片有可能元素数量和元素顺序都不会变，这是为什么呢？我们通过三个小测验来解释造成这个现象的原因。

测验一

下面的代码的输出什么？

func main() {  var s []int  for i := 1; i <= 3; i++ {    s = append(s, i)  }  reverse(s)  fmt.Println(s)}
func reverse(s []int) {  for i, j := 0, len(s) - 1; i < j; i++ {    j = len(s) - (i + 1)    s[i], s[j] = s[j], s[i]  }}

Run it on the Go Playground → https://play.golang.org/p/faJ3WNxpRw

上面的代码中虽然通过值传递了 s，为什么在函数调用后在外部仍能看到 s的变化？

大家都知道切片是指向底层数组的指针，切片本身不存储任何数据。这意味着即使在这里按值传递切片，函数中的切片仍指向相同的内存地址。所以在 reverse()内部使用的切片是一个不同的指针对象，但仍将指向相同的内存地址，共享相同的数组。所以在函数调用之后，该数组中的数字重新排列，函数外部的切片与内部的切片共享着相同的底层数组，所以外部的 s 表现出来的就是它也被排序了。

测验二

我们将在 reverse（）函数内稍微更改一下代码，在函数里添加单个 append调用。它如何改变我们的输出？

func main() {  var s []int  for i := 1; i <= 3; i++ {    s = append(s, i)  }  reverse(s)  fmt.Println(s)}
func reverse(s []int) {  s = append(s, 999)  for i, j := 0, len(s) - 1; i < j; i++ {    j = len(s) - (i + 1)    s[i], s[j] = s[j], s[i]  }}

Run it on the Go Playground → https://play.golang.org/p/tZpkaLA9c_

这一次，在函数外面输出 s时可以看到它保持了排序后的顺序，但是之前的元素 1去哪了？

我们先看一下 slice 的定义

type slice struct {  array unsafe.Pointer  len   int  cap   int}

当我们调用 append时，将创建一个新切片。新切片具有新的“长度”属性，该属性不是指针，但仍指向同一数组。因此，我们函数内的代码最终会反转原始切片所引用的数组，但是原始切片的长度属性还是之前的长度值，这就是造成了上面 1被丢掉的原因。

最终测验

最后我们在 reverse（）函数内部的切片中添加一些额外的数字。函数执行完后在外部打印切片 s看看会输出什么。

func main() {  var s []int  for i := 1; i <= 3; i++ {    s = append(s, i)  }  reverse(s)  fmt.Println(s)}
func reverse(s []int) {  s = append(s, 999, 1000, 1001)  for i, j := 0, len(s)-1; i < j; i++ {    j = len(s) - (i + 1)    s[i], s[j] = s[j], s[i]  }}

Run it on the Go Playground → https://play.golang.org/p/dnbKtLZG8y

在我们的最终测验中，不仅切片长度没有保留，而且切片的顺序也不受影响。为什么？

如前所述，当我们调用 append时，会创建一个新的切片。在第二个测验中，此新切片仍指向同一底层数组，因为它具有足够的容量来添加新元素，因此该数组没有更改，但是在此示例中，我们添加了三个元素，而我们的切片没有足够的容量。于是 系统分配了一个新数组，让切片指向该数组。当我们最终在 reverse函数内开始反转切片中的元素时，它不再影响我们的初始数组，而是在完全不同的数组上运行。

通过 cap 函数验证我们的结论

我们可以通过使用 cap函数来检查传递给 reverse（）的切片的容量来验证正在发生的事情。

func reverse(s []int) {  newElem := 999  for len(s) < cap(s) {    fmt.Println("Adding an element:", newElem, "cap:", cap(s), "len:", len(s))    s = append(s, newElem)    newElem++  }  for i, j := 0, len(s)-1; i < j; i++ {    j = len(s) - (i + 1)    s[i], s[j] = s[j], s[i]  }}

Run it on the Go Playground → https://play.golang.org/p/SBHRj4dPFa

只要不超出切片的容量，我们最终就会在main（）函数中看到reverse函数对切片进行的更改。我们仍然看不到长度的变化，但是我们将看到切片的底层数组中元素的重新排列。

如果在将切片填充到容量长度后，在s上再调用 append（），我们将不会再在 main（）函数中看到这些更改，因为我们的reverse 函数中的代码将一个新切片指向到了一个完全不同的数组。

从切片或数组派生的切片也会受到影响

如果我们恰巧在代码中创建了从现有切片或数组派生的新切片，那么我们也可以看到相同的效果。例如，如果您调用 s2：=s[：]然后将 s2传递到我们的 reverse（）函数中，则可能最终仍会影响 s，因为 s2和 s都指向同一个支持数组。同样，如果我们向s2附加新元素，最终导致其超出支持数组，我们将不再看到对一个切片的更改会影响另一个切片。

严格来说，这不是一件坏事。通过在绝对需要之前不随意复制基础数组，我们最终获得了效率更高的代码，但编写代码时需要考虑到这一点，所以想确保在函数外也能看到函数内程序对切片的更改，那么在函数中一定要把新切片 return 给外部，即使切片是一种引用类型。这也是不要其他编程语言经验带入到 Go上的原因。

这个问题不仅限于切片类型

这不仅限于切片。切片是最容易陷入此陷阱的类型，但是任何带有指针的类型都可能受到影响。如下所示。

type A struct {  Ptr1 *B  Ptr2 *B  Val B}
type B struct {  Str string}
func main() {  a := A{    Ptr1: &B{"ptr-str-1"},    Ptr2: &B{"ptr-str-2"},    Val: B{"val-str"},  }  fmt.Println(a.Ptr1)  fmt.Println(a.Ptr2)  fmt.Println(a.Val)  demo(a)  fmt.Println(a.Ptr1)  fmt.Println(a.Ptr2)  fmt.Println(a.Val)}
func demo(a A) {  // Update a value of a pointer and changes will persist  a.Ptr1.Str = "new-ptr-str1"  // Use an entirely new B object and changes won't persist  a.Ptr2 = &B{"new-ptr-str-2"}  a.Val.Str = "new-val-str"}

Run it on the Go Playground → https://play.golang.org/p/8X-57DvgMm

和这个例子类似，在 Go 中切片的定义如下：

type slice struct {  array unsafe.Pointer  len   int  cap   int}

注意到 array字段实际上是一个指针了吗？这意味着切片会表现得像Go中其他具有嵌套指针的任何类型一样，实际上一点都不特殊，它只是恰好是很少有人关注其内部的类型。

最终，这意味着开发人员需要知道他们传递的数据类型以及所调用的函数可能会如何影响它们。当你将切片传递给其他函数或方法时，应该注意函数可能会，也可能不会更改原始切片中的元素。

同样，你应始终意识到，内部带有指针的结构很容易陷入相同的情况。除非指针本身被更新为引用内存中的另一个对象，否则指针内部数据的任何更改都将被保留。