只读变量的缺失，应该算 Go 语言 “设计缺陷”。举例来说，默认以 error 实例来判断错误类别，但这些可导出全局变量实际可被外部修改，那么就存在隐性风险。

垃圾回收不是万能的，Go 一样存在资源泄露问题。 1. SetFinalizer 虽然垃圾回收器能很好地处理循环引用，可一旦加上 SetFinalizer，事情就不那么美妙了。 显然，这些对象并未被释放。在标准库文档里有这样的描述： Finalizers are run in dependency order: if A points at B, both have finalizers, and they are other...

作为内置类型，通道（channel）从运行时得到很多支持，其自身设计也算得上精巧。但不管怎么说，它本质上依旧是一种队列，当多个 goroutine 并发操作时，免不了要使用锁。某些时候，这种竞争机制，会导致性能问题。

如果是 reflect.Type，可将其缓存，避免重复操作耗时。但 Value 显然不行，因为它和具体对象绑定，内部存储实例指针。换个思路，字段相对于结构，除名称（name）外，还有偏移量（offset）这个唯一属性。利用偏移量，将 FieldByName 变为普通指针操作，就可以实现性能提升。

接口的用途无需多言。但这并不意味着可在任何场合使用接口，要知道通过接口调用和普通调用存在很大差别。首先，相比静态绑定，动态绑定性能要差很多；其次，运行期需额外开销，比如接口会复制对象，哪怕仅是个指针，也会在堆上增加一个需 GC 处理的目标。

Go 使用 channel 实现 CSP 模型。处理双方仅关注通道和数据本身，无需理会对方身份和数量，以此实现结构性解耦。在各文宣中都有 “Don't communicate by sharing memory, share memory by communicating.” 这类说法。但这并非鼓励我们不分场合，教条地使用 channel。

但任何 “便利” 和 “优雅” 的背后，往往都是更复杂的实现机制，无非是语法糖或编译器隐藏了相关细节。最终，这些都会变成额外成本在运行期由 CPU、runtime 负担。甚至因不合理使用，造成性能问题。

延迟调用（defer）确实是一种 “优雅” 机制。可简化代码，并确保即便发生 panic 依然会被执行。如将 panic/recover 比作 try/except，那么 defer 似乎可看做 finally。

内置 map 类型是必须的。首先，该类型使用频率很高；其次，可借助 runtime 实现深层次优化（比如说字符串转换，以及 GC 扫描等）。可尽管如此，也不意味着万事大吉，依旧有很多需特别注意的地方。

对于一些初学者，自知道 Go 里面的 array 以 pass-by-value 方式传递后，就莫名地引起 “恐慌”。外加诸多文章未作说明，就建议用 slice 代替 array，企图避免数据拷贝，提升性能。实际上，此做法有待商榷。某些时候怕会适得其反，倒造成不必要的性能损失。

字符串（string）作为一种不可变类型，在与字节数组（slice, [ ]byte）转换时需付出 “沉重” 代价，根本原因是对底层字节数组的复制。这种代价会在以万为单位的高并发压力下迅速放大，所以对它的优化常变成 “必须” 行为。