之前 go mod 用的比较少，而且一直听社区有各种抱怨，所以也兴趣寥寥。新公司的项目直接使用了 go
mod，本来觉得无非是个简单的工具，不需要学习，结果在一个简单的依赖上却浪费了很多时间。
先来看看我碰到的例子：
package main
import "fmt"
import registry "github.com/apache/dubbo-go/registry"
import zk "github.com/apache/dubbo-go/registry/zookeeper"
import
只要一日自诩工程师，就没有办法放弃学习。本文不算是技术文，只是介绍一些个人的学习方法和经验。如果很多点你已经做到并且做好，一笑了之便可。
阅读书籍
对于工程师来说，从书籍得来的知识是必不可少的。现在很多年轻的程序员会从网络博客来学习技术，但博客内容大多缺乏体系(主要说总结性质的博客内容)，不系统。很多博主为了掩饰自己的未知，遇到不知道的关键点就一笔带过，进而导致缺失。即使原作者非常努力，内容上没有缺失，你能从中获取的也只是别人总结好的知识，没有自己的主动思考，这中间便缺少过程式的沉淀，一味地满足于背诵别人总结好的知识，最后也只不过沦为他人的复读机而已。
对于工程师来说，书籍依然是最重要的知识获取媒介。即使只是通过目录概览，也能获取某个领域的大致蓝图。
目前大部分优秀的技术书籍依然以英文为主，能够读懂英文技术书籍是工程师的硬实力。英语阅读能力怎么训练呢？如果不是为了应试，可以尝试逼迫自己去翻译一些英文文档/文章来进行专门训练。
Go 101 总结了几个可能导致内存泄露的场景：
https://gfw.go101.org/article/memory-leaking.html
goroutine 阻塞在 channel，time.Ticker 不使用但未 stop，以及 for 循环里用 defer
导致泄露，这三个场景其实已经比较常见了，这里就不说了。
我们来看看子切片截取为什么会导致内存泄露。
因为 Go 是一门带 GC 的语言，虽然官方宣传 GC stw
metrics 上报在高并发时会带来性能问题，为了解决问题，有时反而又会带来别的问题。
举个例子，一般的 metrics 上报代码可能是下面这样：
// when request in
metrics.Req(caller, count, latency)
内部实现一般也就是个 UDP 调用，可能碰到的是 fd 锁的问题，在 这篇 [http://xargin.com/lock-contention-in-go/]
里已经写过了。
为了优化这个锁带来的阻塞问题，有些系统会把 metrics 上报改为非阻塞逻辑：
某系统中有类似下面这样的代码：
package main
import (
"sync"
"time"
)
type resp struct {
k string
v string
}
func main() {
res := fetchData()
log.Print(res)
}
func rpcwork() resp {
// do some rpc work
return resp{}
}
func fetchData() (map[string]
