不要使用Logrus
这其实和泛型有关。因为Go语言是一门强类型的静态语言，所以你不可能像NodeJS或者PHP那样绕过数据类型。那如果我们还需要使用通用的类型怎么办呢？比如像Loger，或者ORM，因为只有使用了通用的类型，才能编写出通用的代码，不然每个都要写一次。
最终，我们只能用反射。而 Logrus 大量使用反射，这导致大量分配计数。虽然通常不是一个大问题（取决于代码），但性能很重要，尤其是在大规模、高并发的项目中。虽然这听起来像是一个非常小的优化，但避免反射很重要。如果你看到一些可以不考虑类型而使用结构的代码，它会使用反射并且会对性能产生影响。
例如，Logrus 并不关心类型，但显然 Go 需要知道（最终）。Logrus 怎么办呢？使用反射来检测类型，这是开销。
所以我会更喜欢zerolog，当然zap也不错。两者都宣称零分配，这也是我们希望的，因为它们的性能影响最小。
不要使用encoding/json
当我们需要一个功能、函数的时候，很多人都建议使用标准库。但是标准库中的encoding/json模块是个例外。其实也和上面的例子一样，encoding/json使用反射，这会导致性能不高，并且在编写返回 json 响应的 API 、或者微服务时会造成损失。
比如你可以使用 Easyjson，它很简单，也很高效，它是使用代码生成器来创建将结构转换为 json 所需的代码，以最大限度地减少分配。这是一个手动构建步骤，很烦人。有趣的是json-iterator也使用反射，但速度明显更快，我怀疑是黑魔法。
尽可能不要在goroutine中使用闭包
比如，下面这个示例代码：
大多数人可能期望这会打印数字 0 到 9，就像将任务委托给 goroutine 时那样。
但是实际结果：根据系统，你将得到一两个数字和许多 10。
为什么会这样？闭包可以访问父作用域，因此可以直接使用变量。尽管更新的 linters 可能会警告你“变量闭包捕获”，但并不会要求你重新声明该变量。
Go 的性能名声很大程度上归功于执行的运行时优化，它尝试“猜测”你想要做什么并优化某些执行路径。在此期间，它“捕获”变量并以理论上最有效的方式将它们传递到需要它们的地方（例如，在完成一些非并发操作以释放某些 CPU 上的分配之后）。这种情况下的结果是循环可能会启动 goroutines，goroutines可能会在很晚之后从父作用域接收到 i 的值。不能保证在多次执行此代码时你会看到哪个，可能是数字10，也可以是其他数字。
如果你出于某种原因确实使用了闭包，一定要传递变量i，就像对待每个函数一样对待闭包。