len是很常用的內建函式，可以測量字串、slice、array、channel以及map的長度/元素個數。
不過你真的瞭解len嗎？也許還有一些你不知道的小知識。
我們來看一道GO101的題目，這題也被GO語言愛好者週刊轉載：
package main
import "fmt"
func main() {
var x *struct {
s [][32]byte
}
fmt.Println(len(x.s[99]))
}
題目問你這段程式碼的執行結果，選項有編譯錯誤、panic、32和0。
我們分析一下，別看x的宣告定義一大長串，實際上就是定義了一個有個[][32]byte的結構體，然後x是這個結構體的指標。
然後我們沒有初始化x，所以x是一個值為nil的指標。看到這裡你也許以及有答案了，對nil指標解引用訪問它的成員s，那不就是panic嘛。即使引用x的成員合法，我們的s也沒有初始化，訪問沒有初始化的slice也會panic。
然而這麼想你就錯了，程式碼的實際執行結果是32！
為什麼呢？我們看看len的幫助文件：
For some arguments, such as a string literal or a simple array expression, the result can be a constant. See the Go language specification's "Length and capacity" section for details.
這句話很重要，對於結果是陣列的表示式，len可能會是一個編譯期常量，而且陣列型別的長度在編譯期是可知的，所以熟悉c++的朋友大概會立刻想到這樣的常量是不需要進行實際求值的，簡單型別推導即可獲得。不過口說無憑，我們看看spec裡的描述：
The expression len(s) is constant if s is a string constant. The expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated. Otherwise, invocations of len and cap are not constant and s is evaluated.
如果表示式是字串常量那麼len(s)也是常量。如果表示式s的型別是array或者array的指標，且表示式不是channel的接收操作或是函式呼叫，那麼len(s)是常量，且表示式s不會被求值；否則len和cap會對s進行求值，其計算結果也不是一個常量。
其實說的很清楚了，但還有三點需要說明。
第一個是視為常量的表示式裡為什麼不能含有chan的接收操作和函式呼叫？
這個答案很簡單，因為這兩個操作都是使用這明確希望發生“副作用”的。特別是從chan裡接收資料，還會導致goroutine阻塞，而我們的常量len表示式不會進行求值，這些你期望會發生的副作用便不會產生，會引發一些隱蔽的bug。
第二個是我們注意到了函式呼叫前用non-constant修飾了，這是什麼意思？
按字面意思，一部分函式呼叫其實是可以在編譯期完成計算被當成常量處理的，而另一些不可以。
在進一步深入之前我們先要看看golang裡哪些東西是常量/常量表示式。
- 首先是各種字面量以及對字面量的型別轉換產生的值了，無需多說。
- 一部分內建函式：len、cap、imag、real、complex，它們在引數是常量的時候本身也是常量表示式。
unsafe.Sizeof，因為型別的大小也是編譯期就能確定的，所以它是常量表示式也很好理解。- 所有的常量之間的運算（加減乘除位運算等，除了非常量表示式函式的呼叫）都是常量表示式。
從上面的描述裡可以看出兩點，內建函式和unsafe.Sizeof的呼叫我們可以看成是constant function calls，所有常量表示式除了浮點數和複數表示式都可以在編譯期完成計算。而其他函式比如使用者自定義函式的呼叫，雖然仍然有可能在編譯期被求值優化，但本身不屬於常量表示式。所以語言標準會加以區分。比如下面這個：
func add(x, y int) int {
return x + y
}
func main() {
fmt.Println(add(512, 513)) // 1025
}
如果我們看生成的彙編，會發現求值已經完成，不需要呼叫add：
MOVQ $1025, (SP)
PCDATA $1, $0
CALL runtime.convT64(SB)
MOVQ 8(SP), AX
XORPS X0, X0
MOVUPS X0, ""..autotmp_16+64(SP)
LEAQ type.int(SB), CX
MOVQ CX, ""..autotmp_16+64(SP)
MOVQ AX, ""..autotmp_16+72(SP)
NOP
MOVQ os.Stdout(SB), AX
LEAQ go.itab.*os.File,io.Writer(SB), CX
MOVQ CX, (SP)
MOVQ AX, 8(SP)
LEAQ ""..autotmp_16+64(SP), AX
MOVQ AX, 16(SP)
MOVQ $1, 24(SP)
MOVQ $1, 32(SP)
NOP
CALL fmt.Fprintln(SB)
MOVQ 80(SP), BP
ADDQ $88, SP
RET
很明顯的，1025已經在編譯期求值了，然而add的呼叫不是常量表示式，所以下面的程式碼會報錯：
const number = add(512, 513) // error!!!
// example.go:11:7: const initializer add(512, 513) is not a constant
spec給出的例項是呼叫的內建函式，內建函式也只有在引數是常量的情況下被呼叫才算做常量表示式：
const (
c4 = len([10]float64{imag(2i)}) // imag(2i) is a constant and no function call is issued
c5 = len([10]float64{imag(z)}) // invalid: imag(z) is a (non-constant) function call
)
var z complex128
所以len的表示式裡如果用了non-constant的函式呼叫，那麼就len本身不能算是常量表示式了。
這就有了最後一個疑問，題目中的x不是常量，為什麼len的結果是常量呢？
標準只說表示式裡不能有chan的接收和非常量表示式的函式呼叫，沒說其他的不可以。你也可以這麼理解，表示式都有結果值，任何值除了無型別常量（這裡顯然不是）都是要有一個確定的型別的，只要這個型別是陣列或者陣列的指標，那len就能獲得陣列的長度，而這一切不需要s一定是常量表示式，編譯器可以簡單推匯出表示式的值的型別。不能包含non-constant function calls和chan接收是我在第一點裡解釋的，杜絕所有可能的副作用發生從而保證即使不對錶達式求值程式也是正確的，不包含這兩個操作的表示式既可以是常量的也可以不是，所以這裡我們能用x.s[99]作為len的引數。
說了這麼多，只要len的引數型別為array或者array的指標並且符合要求，就不會進行求值，而題目裡的表示式正好滿足這點，所以雖然我們看起來是會導致panic的程式碼，但是本身並未進行實際求值，因此程式可以正常執行。另外cap也遵循同樣的規則。
最後，還有個小測驗，檢驗一下自己的學習吧：
// 以下哪些語句是正確的，哪些是錯誤的
var slice [][]*[10]int
const (
a = len(slice[10000000000000][4]) // 1
b = len(slice[1]) // 2
c = len(slice) // 3
d = len([1]int{1024}) // 4
e = len([1]int{add(512, 512)}) // 5
g = len([unsafe.Sizeof(slice)]int{}) // 6
g = len([unsafe.Sizeof(slice)]int{int(unsafe.Sizeof(slice))}) // 7
)