這個(gè)現(xiàn)象確實(shí)是編譯器優(yōu)化導(dǎo)致的，我們可以從源碼中找出一些證據(jù)。

137995 0000000000483200 <main.main>:
……
138009  48323b:      0f 11 44 24 08          movups %xmm0,0x8(%rsp)
138010  483240:      e8 bb a4 fb ff          callq  43d700 <runtime.stringtoslicebyte>
138011  483245:      48 8b 44 24 20          mov    0x20(%rsp),%rax
138012  48324a:      48 8b 4c 24 28          mov    0x28(%rsp),%rcx
……

我們把程序反匯編，如上，可以看到對(duì)于 s := []byte("") 這樣的語(yǔ)句，編譯器會(huì)為我們生成 stringtoslicebyte函數(shù)進(jìn)行從string到slice的轉(zhuǎn)換。這個(gè)函數(shù)定義在：

146 func stringtoslicebyte(buf *tmpBuf, s string) []byte {
147        var b []byte
148        if buf != nil && len(s) <= len(buf) {
149                *buf = tmpBuf{} 
150                b = buf[:len(s)]
151        } else {
152                b = rawbyteslice(len(s))
153        }
154        copy(b, s)
155        return b
156 }
"runtime/string.go" 443 lines --22%--                

tmpBuf定義為一個(gè)長(zhǎng)度為32的數(shù)組。

9 // The constant is known to the compiler.
10 // There is no fundamental theory behind this number.
11 const tmpStringBufSize = 32
12
13 type tmpBuf [tmpStringBufSize]byte
14

當(dāng)stringtoslicebyte走第一個(gè)分支時(shí)，從棧上分配內(nèi)存，如果從棧上分配，就是分配一個(gè)長(zhǎng)度為32的數(shù)組，32是一個(gè)寫死的和編譯器約定好的值。

當(dāng)stringtoslicebyte走第二個(gè)分支時(shí)，從堆上分配內(nèi)存，如果從堆上分配，就是根據(jù)字符串的實(shí)際長(zhǎng)度進(jìn)行分配。

255 // rawbyteslice allocates a new byte slice. The byte slice is not zeroed.
256 func rawbyteslice(size int) (b []byte) {
257        cap := roundupsize(uintptr(size))
258        p := mallocgc(cap, nil, false)
259        if cap != uintptr(size) {
260                memclrNoHeapPointers(add(p, uintptr(size)), cap-uintptr(size))
261        }
262
263        *(*slice)(unsafe.Pointer(&b)) = slice{p, size, int(cap)}
264        return
265 }
"runtime/string.go" 443 lines --47%--               

我們接著搜索編譯器的源碼，可以找到stringtoslicebyte的生成邏輯。

1635        case OSTRARRAYBYTE:
1636                a := nodnil()
1637
1638                if n.Esc == EscNone {
1639                        // Create temporary buffer for slice on stack.
1640                        t := types.NewArray(types.Types[TUINT8], tmpstringbufsize)
1641
1642                        a = nod(OADDR, temp(t), nil)
1643                }
1644
1645                n = mkcall("stringtoslicebyte", n.Type, init, a, conv(n.Left, types.Types[TSTRING]))
"cmd/compile/internal/gc/walk.go" 3928 lines --40%--                                                                   

根據(jù)注釋看，編譯器判斷是否在棧上分配的條件，是這個(gè)對(duì)象是否會(huì)逃逸——
編譯器會(huì)判斷一個(gè)對(duì)象是否會(huì)在當(dāng)前函數(shù)外被引用，如果不會(huì)就可以通過(guò)在當(dāng)前棧上分配該對(duì)象，無(wú)需GC處理，達(dá)到優(yōu)化的目的。
這個(gè)過(guò)程屬于編譯器逃逸分析（優(yōu)化）的一部分。逃逸分析的相關(guān)源碼在：
"cmd/compile/internal/gc/esc.go"

通過(guò)如下命令可以獲取到編譯器逃逸分析的結(jié)果

沒(méi)有fmt.Println(s)時(shí)的逃逸分析結(jié)果：

$ go tool compile -m test.go
test.go:7:16: cap(s) escapes to heap
test.go:7:24: len(s) escapes to heap
test.go:6:12: main ([]byte)("") does not escape
test.go:7:12: main ... argument does not escape

有fmt.Println(s)時(shí)的逃逸分析結(jié)果：

$ go tool compile -m test.go
test.go:7:16: cap(s) escapes to heap
test.go:7:24: len(s) escapes to heap
test.go:8:12: s escapes to heap
test.go:6:12: ([]byte)("") escapes to heap
test.go:7:12: main ... argument does not escape
test.go:8:12: main ... argument does not escape

以上，基本上就解釋了我們所看到的現(xiàn)象。

這個(gè)問(wèn)題很有意思，從結(jié)果上來(lái)看，編譯器肯定是對(duì)棧上分配的臨時(shí)數(shù)組變量做了優(yōu)化（臨時(shí)分配的固定大小的容量），若一但操作了該數(shù)組變量，那么會(huì)根據(jù)實(shí)際使用情況更新數(shù)組變量的容量大小。

此外，如果是將該數(shù)組定義成包內(nèi)部變量或者全局變量，這個(gè)cap的結(jié)果也會(huì)是0，因?yàn)樗鼤?huì)在堆上進(jìn)行分配。

我也僅僅是根據(jù)測(cè)試結(jié)果進(jìn)行的猜測(cè)，具體內(nèi)部實(shí)現(xiàn)細(xì)節(jié)可能需要大牛來(lái)科普以下。