关于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 == 0s := make([]int{}, 0, 1)   // cap == 1s := []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 的小陷阱），须要注意。