Go Web性能瓶颈主因是HTTP链路低效设计：需避免handler中同步阻塞、重复序列

化、未复用对象及过度日志；应移出耗时操作、用sync.Pool复用小对象、显式配置http.Server、静态资源交由CDN托管。

Go Web 项目性能瓶颈通常不在语言本身，而在 HTTP 处理链路中的低效设计——比如同步阻塞、重复序列化、未复用对象、日志/中间件过度侵入。优化得从请求生命周期里找“可剪枝”的环节。

避免在 http.HandlerFunc 中做同步耗时操作

数据库查询、HTTP 调用、文件读写如果直接写在 handler 里，会阻塞 goroutine，快速吃光 net/http 默认的 goroutine 池（实际无上限但受系统资源制约）。尤其当依赖服务响应慢时，连接堆积、超时雪崩。

实操建议：

• 把耗时操作移入 goroutine 或使用带超时的 context.WithTimeout 控制边界
• 对强依赖服务，考虑加熔断（如 gobreaker）或降级返回缓存数据
• 不要在 handler 里用 time.Sleep 模拟延迟——这是压测时最容易误用的反模式

示例错误写法：

func badHandler(w http.ResponseWriter, r *http.Request) {
    time.Sleep(2 * time.Second) // 阻塞整个 goroutine
    json.NewEncoder(w).Encode(map[string]string{"ok": "done"})
}

用 sync.Pool 复用高频分配的小对象

JSON 编码器、bytes.Buffer、自定义结构体实例等，在高 QPS 下频繁 new / make 会显著增加 GC 压力。Go 的 sync.Pool 是零成本复用的首选。

实操建议：

• 为 json.Encoder 或 bytes.Buffer 建立全局 sync.Pool，Get() 后重置状态，Put() 前清空内容
• 池中对象生命周期由 Go 管理，不保证一定复用，也不保证不被 GC；别往里塞大对象或含指针的复杂结构
• 注意：sync.Pool 不适合长期存活的对象，只适用于“一次请求内创建+销毁”的短命对象

典型用法：

var bufPool = sync.Pool{
    New: func() interface{} { return new(bytes.Buffer) },
}
func handler(w http.ResponseWriter, r *http.Request) {
    buf := bufPool.Get().(*bytes.Buffer)
    buf.Reset()
    defer bufPool.Put(buf)
    json.NewEncoder(buf).Encode(data)
    w.Header().Set("Content-Type", "application/json")
    w.Write(buf.Bytes())
}

关闭默认 http.DefaultServeMux，手动配置 http.Server

用 http.ListenAndServe 启动服务时，默认使用全局 http.DefaultServeMux 和 http.DefaultServer，它们缺乏细粒度控制：无法设置读写超时、禁用 HTTP/1.1 keep-alive、调整 TLS 设置，甚至无法优雅关机。

实操建议：

• 显式构造 http.Server，设置 ReadTimeout、WriteTimeout、IdleTimeout 防连接僵死
• 用 http.TimeoutHandler 包裹 handler 实现 per-route 超时，比在 handler 内部用 context 更早中断
• 生产环境务必禁用 Server.DebugFlags，避免泄露内部信息

关键配置片段：

srv := &http.Server{
    Addr:         ":8080",
    Handler:      myRouter,
    ReadTimeout:  5 * time.Second,
    WriteTimeout: 10 * time.Second,
    IdleTimeout:  30 * time.Second,
}

静态资源走 CDN，API 层专注逻辑，别让 Go 处理 fs.FileServer

用 http.FileServer 直接提供前端 JS/CSS/图片，看似方便，实则浪费 Go 的并发优势：它会同步读取磁盘、无压缩、无缓存头、无法利用浏览器强缓存。QPS 上千后，I/O 成瓶颈，且易被慢速客户端拖垮。

实操建议：

• 所有静态资源构建后上传 CDN，通过独立域名访问（如 static.example.com）
• API 接口统一返回 JSON，前端按需加载；若必须本地托管，至少用 http.StripPrefix + http.ServeFile 替代 FileServer，并加 Cache-Control 头
• 开发期可用 embed.FS 将静态资源编译进二进制，但上线后仍建议分离部署

容易忽略的一点：即使用了 embed.FS，也要手动设置 Content-Type 和 ETag，否则浏览器不会缓存。