goroutine泄漏比CPU占用更隐蔽，需优先排查；高并发下响应变慢、内存持续上涨多因协程未回收，应设I/O超时、避免无限阻塞、限流goroutine、优化JSON序列化、合理配置数据库连接池、中间件禁用同步阻塞操作。

goroutine 泄漏比 CPU 占用更隐蔽，先查它

高并发下服务响应变慢、内存持续上涨，大概率不是 CPU 瓶颈，而是 goroutine 没被回收。比如用 http.Client 发起超时未设的请求，或在 select 中漏写 default 导致协程永久阻塞。

• 用 pprof 快速定位：

  curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'

  查看堆积的调用栈
• 所有带超时的 I/O 操作必须显式设置：用 context.WithTimeout 包裹 http.NewRequestWithContext，而不是只设 client.Timeout
• 避免在循环中无节制启动 goroutine：改用带缓冲的 chan 控制并发数，或用 semaphore.NewWeighted（golang.org/x/sync/semaphore）限流

JSON 序列化是高频性能热点，别用默认 encoder

微服务间大量使用 JSON 通信，json.Marshal 和 json.Unmarshal 在高 QPS 下会成为 CPU 和 GC 压力源，尤其字段多、嵌套深时。

• 优先用 easyjson 或 ffjson 生成静态 marshal/unmarshal 方法，避免反射；go-json（github.com/goccy/go-json）在 Go 1.20+ 上兼容性更好且无需代码生成
• 禁止在 hot path 上对同一结构体反复 json.Marshal：提前序列化为 []byte 缓存（注意浅拷贝问题），或用 sync.Pool 复用 bytes.Buffer
• 如果协议允许，考虑切换到 Protocol Buffers（protobuf）：体积小、解析快、类型安全，gRPC 默认即用此方案

数据库连接池配置不当，比 SQL 慢查询更致命

很多团队花大力气优化 SQL，却忽略 sql.DB 的 SetMaxOpenConns 和 SetMaxIdleConns。连接池过小会导致请求排队，过大则压垮数据库；空闲连接不回收会拖慢服务重启和故障转移。

• SetMaxOpenConns 不宜超过数据库单实例连接上限的 70%；一般建议设为 2 * CPU 核数 起步，再根据 pg_stat_activity 或 MySQL show processlist 观察实际峰值
• SetMaxIdleConns 应 ≤ SetMaxOpenConns，且建议设为非零值（如 5），否则每次请求都新建连接，TLS 握手开销显著
• 务必调用 db.SetConnMaxLifetime（如 30 * time.Minute）：防止因数据库连接超时、网络中断导致的 stale connection 报错

HTTP 中间件里做同步阻塞操作，等于给每个请求加锁

日志、鉴权、熔断等中间件若调用同步外部依赖（如 Redis 同步命令、HTTP 同步调用、文件 IO），会直接卡住整个 http.ServeMux 的 goroutine，QPS 断崖下跌。

立即学习“go语言免费学习笔记（深入）”；

• 所有中间件内对外部服务的调用，必须用带上下文的异步客户端：如 redis.Client.Get(ctx, key)，并确保 ctx 带超时
• 日志写入不要直写磁盘：用 zerolog.New(os.Stdout) 配合 With().Timestamp().Str("service", "xxx") 结构化输出，再由日志采集器（Filebeat / Fluent Bit）统一落盘
• 熔断器选 sony/gobreaker 而非简单计数器：它支持半开状态、滑动窗口统计，不会因瞬时抖动误熔断

真实线上问题往往藏在「看起来没问题」的配置和调用链里——比如一个没设 context 超时的 http.Get，可能让整个服务在下游抖动时集体 hang 住十几秒。