关于go:Slice-capacity-相关的两个场景

场景 1

// s 为 []int, capacity 未知。s1 := append(s, 9)
s2 := append(s, 12)

s1 和 s2 的值未知，s[0] 可能是 12，也有可能是 9。如果在 append 一个元素之后 s 不会扩容，那么 s1[len(s)] 的值将会是 12。

场景 2

对于 slice 的 cap 到底是多少的问题。

s := []int{}               // cap == 0
s := make([]int{}, 0, 1)   // cap == 1
s := []byte{}              // cap == 0

逃逸状况的 cap

func capVal() []byte {
    raw := ""
    s := []byte(raw)
    s2 := []byte(raw)
    fmt.Printf("s cap: %d, s2 cap: %d.\n", cap(s), cap(s2))
    return s2
}
// s cap: 32, s2 cap: 0.

这里特地要小心，因为函数 capVal 返回了 s2，因而 s2 被视作逃逸变量，因而和在栈上的变量 s，应用了不同的初始化 capacity。

很好的一篇参考资料：Go 中 string 转 []byte 的陷阱

上述两个场景都是公司共事在理论代码中发现的 bug（或者说，Go 的小陷阱），须要注意。