Go 项目做的比较大(主要说代码多，参与人多)之后，可能会遇到类似下面这样的问题： * 程序老是半夜崩，崩了以后就重启了，我也醒不来，现场早就丢了，不知道怎么定位 * 这压测开压之后，随机出问题，可能两小时，也可能五小时以后才出问题，这我蹲点蹲出痔疮都不一定能等到崩溃的那个时间点啊 * 有些级联失败，最后留下现场并不能帮助我们准确地判断问题的根因，我们需要出问题时第一时间的现场 Go 内置的 pprof 虽然是问题定位的神器，但是没有办法让你恰好在出问题的那个时间点，把相应的现场保存下来进行分析。特别是一些随机出现的内存泄露、CPU 抖动，等你发现有泄露的时候，可能程序已经 OOM 被 kill

填坑。。 https://github.com/cch123/golang-notes/blob/master/context.md ascii 图太多，blog 上没法看。就这样

http 标准库 服务端 请求处理 package main import ( "io" "log" "net/http" ) func sayhello(wr http.ResponseWriter, r *http.Request) { wr.Header()["Content-Type"] = []string{"application/json"} io.WriteString(wr, "hello") } func main() { http.HandleFunc(

几年前写过一篇 如何使你的代码达到 awesome-go 的入选标准 [http://xargin.com/how-to-meet-the-quality-standard-of-awesome-go/] 。几年过去了，标准和工具都有所变化。 linter 已经换了两代，刚开始是散乱的 golint，go vet，staticcheck，后来出现了 gometalinter，把散乱的工具集集成到一起。 gometalinter 时代，我把这个工具集成到了当时组内所有项目 Makefile 里，合并代码前要求提交者自行执行 make lint 来检查不符合规范的代码并修正，可惜 Makefile 里的命令没有强制约束，某些没有追求的程序员根本不把君子之约当回事，

坊间传言 fasthttp 在某些场景下比 nginx 还要快，说明 fasthttp 中应该是做足了优化。我们来做一些相关的验证工作。 先是简单的 hello server 压测。下面的结果是在 mac 上得到的，linux 下可能会有差异。 fasthttp： ~ ❯❯❯ wrk -c36 -t12 -d 5s http://127.0.0.1:8080 Running 5s test