

新闻资讯
行业动态pprof 是性能优化的必选项,必须先用 go tool pprof 定位 CPU、内存、goroutine 瓶颈,再针对性优化;盲目改代码90%是浪费时间。
pprof 不是可选项,是必选项——没跑过 go tool pprof 就动手改代码,90% 的“优化”都在浪费时间。
新手最容易犯的错:一上来就重写 for 循环、换 strings.Builder、加 sync.Pool。但实际可能 95% 时间花在数据库连接上,或者 HTTP 客户端没复用 http.Transport。
import _ "net/http/pprof"
func main() {
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()
// your app
}go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30go tool pprof http://localhost:6060/debug/pprof/heapgo tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2
fmt.Sprintf 看似慢,但 profile 显示它只占 0.3%,而 JSON 解析占 68% —— 那就该换 jsoniter 或预分配 json.RawMessage,不是去动字符串拼接。开发阶段的“性能”首先是人等得少。Golang 编译快,但默认配置下,频繁 go test 或 go build 仍会卡顿,尤其模块多、依赖深时。
.zshrc 或 .bashrc):export GOPROXY=https://goproxy.cn export GOCACHE=$HOME/.cache/go-build export GOMODCACHE=$HOME/.cache/go-mod
t.Parallel()(仅限无共享状态)TestMain 里,避免每个测试都连 DB / 启 HTTP server
部测试用 go test -run="^TestLogin$" -v,别总 go test ./...
-ldflags="-s -w",链接阶段快 20%+,二进制小 30%,且不影响调试(调试用 dlv 本身不依赖符号表)。sync.Pool 和预分配不是所有对象都值得池化,但以下两类几乎必赢:
— 短生命周期的切片/缓冲区(如 HTTP body 读取、JSON 解析临时 buf)
— 结构体指针(如 *User, *RequestCtx),尤其在中间件或 handler 中高频 new
func handle(r *http.Request) {
buf := make([]byte, 4096) // 每次请求都 malloc
r.Body.Read(buf)
}var bufPool = sync.Pool{
New: func() interface{} { return make([]byte, 4096) },
}
func handle(r *http.Request) {
buf := bufPool.Get().([]byte)
defer bufPool.Put(buf)
r.Body.Read(buf)
}sync.Pool 不保证对象复用,GC 时会清空,别存带状态的对象(如已部分填充的 map)make([]int, 0, 100) 比 make([]int, 100) 少一次初始化开销新手常被“内联能去函数调用开销”吸引,但 Go 编译器自己会做大部分内联决策。手动加 //go:noinline 或 //go:inline 反而容易破坏逃逸分析,导致更多堆分配。
bytes.Buffer / strings.Builder 替代 + 拼接字符串(string 是不可变的,+ 每次都新 alloc)map[string]struct{} 代替 map[string]bool 节省内存(struct{} 占 0 字节)reflect.DeepEqual 前先判指针相等:if a == b { return true }(避免反射开销)pprof 接入本地开发流程,跑三次真实请求、看一眼火焰图,剩下的事就清晰了。