Go运行时参数必须显式调优：GOMAXPROCS设为逻辑核心数，GOGC=20（或50），开启GODEBUG=schedtrace；HTTP连接池需配置MaxIdleConns等参数；sync.Pool仅适用于短生命周期对象；pprof采样须绕过HTTP handler并先确认GOMAXPROCS已优化。
Go 运行时参数必须显式调优，不能依赖默认值
Go 程序在高并发场景下卡顿、CPU 利用率上不去，往往不是代码问题，而是 GOMAXPROCS、GOGC、GODEBUG 这些运行时参数没动过。默认值只适合开发机单核调试，生产环境必须重设。
-
GOMAXPROCS建议设为 CPU 逻辑核心数（runtime.NumCPU()），而非留空——留空在容器中可能被限制为 1，导致所有 goroutine 挤在单个 P 上调度争抢 -
GOGC=20是高频分配场景的常用值：堆增长 20% 就触发 GC，避免内存持续膨胀拖慢分配器；但若业务对象生命周期长，可适度放宽到50减少 GC 频次 -
GODEBUG=schedtrace=1000必须开：每秒输出调度器状态，观察goroutines是否持续上涨、runqueue是否堆积，这是判断 goroutine 泄漏的第一手证据 - 不要设
GOMAXPROCS超过物理核心数 × 2——过度并行反而引发 M 切换和缓存失效，实测在 32 核机器上设为 64 后 QPS 反降 12%
http.Server 和 http.Client 的连接池参数必须重写
默认的 http.DefaultClient 和未配置的 http.Server 是高并发下的隐形瓶颈，现象是 QPS 卡在 200–300 不再上升，netstat -an | grep :80 | wc -l 显示大量 TIME_WAIT 或 ESTABLISHED 连接堆积。
-
MaxIdleConns和MaxIdleConnsPerHost必须显式设为相同值（如1000），否则跨域名请求会抢不到空闲连接 -
IdleConnTimeout设为略大于后端平均响应时间（如5 * time.Second），太短导致反复建连，太长耗尽 fd -
ReadTimeout/WriteTimeout必须设（建议 ≤5 * time.Second），防止慢请求长期占着 goroutine - 不要用
http.DefaultClient——它共享的 Transport 在压测中会因连接池过小直接阻塞，必须 new 一个独立 client 实例
sync.Pool 使用有严格前提，误用等于加重 GC
sync.Pool 不是通用缓存，把它当 map 存业务对象或复用已有实例，会导致对象长期驻留堆上，延迟 GC 回收，反而出现在 pprof 中 runtime.mallocgc 占比飙升。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 只用于高频创建 + 短期使用 + 生命周期可控的对象：比如
*bytes.Buffer、json.Decoder、http.Request复制体 -
New函数必须返回全新对象，不能 return 已存在的实例（否则残留字段污染后续请求） - 每次
Get()后必须显式Reset()（如buf.Reset()）或清空字段，否则数据错乱 - 禁止在 long-running goroutine（如定时任务）里高频
Get()：sync.Pool的清理时机依赖主 goroutine 的调用节奏，后台协程不触发 GC 清理
pprof 采样要绕过 HTTP handler 干扰
直接访问 /debug/pprof/profile?seconds=30 会把 handler 自身的路由匹配、中间件执行等开销全计入 profile，尤其在高 QPS 下，这部分噪音可能占样本 15%+，掩盖真实热点函数。
立即学习“go语言免费学习笔记（深入）”；
- 用
pprof.StartCPUProfile+time.AfterFunc在代码中精准启动采样，避开 HTTP 入口链路 - 对关键路径（如 DB 查询、JSON 序列化）单独打点采样，而不是整条请求链一把抓
- 采样时关闭日志、监控埋点等非核心逻辑，避免干扰火焰图识别真实瓶颈
- 确认
runtime.GOMAXPROCS已调优后再采样——否则火焰图里大量时间花在runtime.schedule，不是业务问题，是调度器被压垮了
实际部署时最容易被忽略的是：goroutine 泄漏和连接池参数错误往往同时存在，一个没解决，另一个的优化效果就出不来。先用 /debug/pprof/goroutine?debug=2 看堆栈，再查连接数，顺序不能反。
