@Ipsum 这个问题在 1.23 版已经解决了，不会又问题了。

https://github.com/UltimateYhq/100-GO-mistakes

看这种常规错误避免，剩下 gc 帮你兜底应该问题不大。

1. checklist 各种，这里手打太麻烦了，你可以直接上网搜一下，主要还是协程泄露比较多，全局变量的泄露很少的，避免协程被 chan 阻塞，基本就可以了
2. 建立优雅重启的方案，如果你的程序一小时可以无损的重启一次，加上监控，内存大了起个新的实来接管流量，这个可以把影响降到最低
3.其实比起内存泄露，你更应该担心的是 panic 导致的进程异常退出，没处理好容易有各种的脏数据

懂了，先搞一个启动器，接管 tcp/udp ，启动主程序，并定时启动新的，关掉旧的……
客户端连接的时候映射到新启动的，旧的自然就不需要了。

完美~

等等，这不就是集群么

没用过 go ，真的有企业采用定时重启方案？震惊

@oneisall8955 #26 同样震惊

一般只需要注意 goroutine 结束不了的情况，比如一直阻塞。

- 统计 gorouting 使用场景并上报 metric 。如果是 HTTP 服务可以接口路径作为一个 label ，这样即使发生 goroutine 泄露也能快速定位是哪个场景的问题。
- 少修改全局变量。全局变量修改会涉及竞态问题也麻烦
- pprof 可以不开启，但是可以做个内部调用接口开启，在发生内存泄漏的时候开启然后收集即可，这样对性能影响也不大。

重启方案 当然是最简单实用的方案啊

线上默认把 pprof 打开就行了，我写了四五年 go 了，还从来没遇到过内存泄露。

一般 fd 、goroutine 之类的泄露比较多。