原文链接：
https://github.com/sxs2473/go…本文使用
Creative Commons Attribution-ShareAlike 4.0 International 协议进行授权许可。
总结
保持简单
从最简单的代码开始。
测量！ 分析你的代码来找到瓶颈， 不要猜测 !
如果性能还不错， 收手吧 ！你不需要优化所有的代码，只需要针对影响最大的部分就可以了。
不是程序的每部分都需要高性能
对于大多数关注性能的应用程序，适用80/20规则。80%的时间将花在20%的代码上。
随着应用程序的增长或业务发展，这些性能问题的重点将会变化。
不要留着对性能不重要的复杂代码，如果瓶颈转移到其他地方，就用更简单的实现重写它。
Go 编译器针对简单代码进行了优化
总是写你能写出的最简单的代码，编译器针对简单代码进行了优化。我不说 惯用的 ，因为我不喜欢我们在讨论 Go 时使用这个词。我只说简单，而不是 聪明 的代码。
更短的代码就是更快； Go 不是 C++，不要指望编译器解开复杂的抽象。
更短的代码体积更小；这对 CPU 的缓存很重要。
注意二次方复杂度的操作
If a program is too slow, it must have a loop — Ken Thompson
大多数程序在少量数据的情况下表现良好。 这是 Pike’s 3rd rule 思想背后的精髓。
然而，当数据集很大时，任何接触输入集不止一次的东西，例如，对于集合中的每个元素，对集合中的每个其他元素进行测试，都有可能成为性能方面的大问题。
限制程序各部分之间的通信和协调点，以遵守 Amdahl定律。
性能经验法则
网络/硬盘 io >> 内存分配 >> 函数调用 （ >> 表示远远大于，意味着数量级之间的差距）
如果您的程序主要工作是网络或硬盘访问，那么不要费心去优化内存分配方面的事情。重点关注如何利用缓冲和批处理，以减少等待IO的时间。
如果您的程序是主要工作是分配和管理内存，不要费心去优化函数内联、循环展开等事情。
注意内存分配的使用，尽量避免不必要的分配。
不要为了可靠性而牺牲性能
I can make things very fast if they don’t have to be correct. — Russ Cox
最后，不要为了可靠性而牺牲性能
Readable means reliable — Rob Pike
性能和可靠性同样重要。
