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或 MySQLshow 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 住十几秒。
