前言
Go 是一门简单有趣的编程语言，与其他语言一样，在使用时不免会遇到很多坑，不过它们大多不是 Go 本身的设计缺陷。如果你刚从其他语言转到 Go，那这篇文章里的坑多半会踩到。
如果花时间学习官方 doc、wiki、讨论邮件列表、 Rob Pike 的大量文章以及 Go 的源码，会发现这篇文章中的坑是很常见的，跳过这些坑，能减少大量调试代码的时间。
高级篇：52-58
52.使用指针作为方法的 receiver
只要值是可寻址的，就可以在值上直接调用指针方法。即是对一个方法，它的 receiver 是指针就足矣。
但不是所有值都是可寻址的，比如 map 类型的元素、通过 interface 引用的变量：
53.更新 map 字段的值
如果 map 一个字段的值是 struct 类型，则无法直接更新该 struct 的单个字段：
因为 map 中的元素是不可寻址的。需区分开的是，slice 的元素可寻址：
注意：不久前 gccgo 编译器可更新 map struct 元素的字段值，不过很快便修复了，官方认为是 Go1.3 的潜在特性，无需及时实现，依旧在 todo list 中。
更新 map 中 struct 元素的字段值，有 2 个方法：
- 使用局部变量
使用指向元素的 map 指针
但是要注意下边这种误用：
54.nil interface 和 nil interface 值
虽然 interface 看起来像指针类型，但它不是。interface 类型的变量只有在类型和值均为 nil 时才为 nil
如果你的 interface 变量的值是跟随其他变量变化的（雾），与 nil 比较相等时小心：
如果你的函数返回值类型是 interface，更要小心这个坑：
55.堆栈变量
你并不总是清楚你的变量是分配到了堆还是栈。
在 C++ 中使用 new 创建的变量总是分配到堆内存上的，但在 Go 中即使使用 new()、make() 来创建变量，变量为内存分配位置依旧归 Go 编译器管。
Go 编译器会根据变量的大小及其 "escape analysis" 的结果来决定变量的存储位置，故能准确返回本地变量的地址，这在 C/C++ 中是不行的。
在 go build 或 go run 时，加入 -m 参数，能准确分析程序的变量分配位置：
56.GOMAXPROCS、Concurrency（并发）and Parallelism（并行）
Go 1.4 及以下版本，程序只会使用 1 个执行上下文 / OS 线程，即任何时间都最多只有 1 个 goroutine 在执行。
Go 1.5 版本将可执行上下文的数量设置为 runtime.NumCPU() 返回的逻辑 CPU 核心数，这个数与系统实际总的 CPU 逻辑核心数是否一致，取决于你的 CPU 分配给程序的核心数，可以使用 GOMAXPROCS 环境变量或者动态的使用 runtime.GOMAXPROCS() 来调整。
误区：GOMAXPROCS 表示执行 goroutine 的 CPU 核心数，参考文档
GOMAXPROCS 的值是可以超过 CPU 的实际数量的，在 1.5 中最大为 256
57.读写操作的重新排序
Go 可能会重排一些操作的执行顺序，可以保证在一个 goroutine 中操作是顺序执行的，但不保证多 goroutine 的执行顺序：
运行效果：
如果你想保持多 goroutine 像代码中的那样顺序执行，可以使用 channel 或 sync 包中的锁机制等。
58.优先调度
你的程序可能出现一个 goroutine 在运行时阻止了其他 goroutine 的运行，比如程序中有一个不让调度器运行的 for 循环：
for 的循环体不必为空，但如果代码不会触发调度器执行，将出现问题。
调度器会在 GC、Go 声明、阻塞 channel、阻塞系统调用和锁操作后再执行，也会在非内联函数调用时执行：
可以添加 -m 参数来分析 for 代码块中调用的内联函数：
你也可以使用 runtime 包中的 Gosched() 来 手动启动调度器：
