Go服务器性能调优：避坑选型，QPS翻倍实战

发布时间：2026-11-07 08:23:12 所属栏目：系统来源：DaWei

导读：　　后台又卡了一下。我盯着那个绿色的 CPU 柱状图，它本来该平着喘气，结果突然撅起个尖儿——像被谁踩了尾巴。去年11月份那会儿，我们整个推荐位全挂过一次，不是崩，是卡成PPT，用户刷三下才出一个feed，审核那边直接在群里甩截

　　后台又卡了一下。我盯着那个绿色的 CPU 柱状图，它本来该平着喘气，结果突然撅起个尖儿——像被谁踩了尾巴。去年11月份那会儿，我们整个推荐位全挂过一次，不是崩，是卡成PPT，用户刷三下才出一个feed，审核那边直接在群里甩截图：“这哪是推荐，这是考古。”

　　其实我原以为是 goroutine 泄漏，查了俩钟头 pprof，内存没涨，协程数稳得一批，反倒是 runtime 的调度延迟高得离谱。我删掉三行 log.Printf，QPS 立刻跳了 17%，我说不至于吧？结果运维小哥敲我工位隔板：“你是不是把 zap 配成 sync 了？”……对，就是那个 debug 级别还写磁盘的 zap.Config。我改了三遍，第二遍忘了关 dev mode，第三遍才想起来日志里有个 WithCaller(true) 在疯狂 syscall。说白了，咱连 logger 都没配明白，就敢说“Go 高并发”？

　　窗外天已经黑了，对面楼还亮着几扇窗，我盯得眼酸。选型会上 SEO 那边提了三次“要不要上 Rust”，主编叼着根没点的烟，手指在笔记本边缘搓出毛边。没人问为什么我们的 /api/v2/recommend 耗时 320ms 却只跑 400 QPS——而隔壁采集组用 gin 写的 /v1/urls 只有 89ms、却撑着 1100 QPS。没人问，但我知道：他们没在中间塞三个 context.WithTimeout 嵌套两层，也没把 JSON 解码塞进 defer 里等 GC 回收。我偷懒过，用 map[string]interface{} 接一切请求体，后来发现 json.Unmarshal 直接干翻了 cpu cache line，换回 struct 后 GC 停顿少了一半。这事我没跟任何人讲，怕被说矫情。

　　饮水机没水了，我拧开瓶装水喝了一口，喉咙发紧。优胜劣汰？哈。真不是啥高大上的结论——就是活下来的那几个服务，全是绕开了 net/http 默认的 http.Server{ReadTimeout: 0} 这种祖传配置；全是没在 handler 里调 redis.Do("GET", key) 调到第五次才想起 pipeline；全是把 gorm.Open 拉到 init 里、而不是每次请求 new 一个 db 实例的傻逼操作。我同事老张上周重写了个 token 校验中间件，不用 jwt-go，改用手写的 base64url + hmac，他说“解码不比验证慢，可验证完还要 decode payload，不如一步到位”。我听了想拍桌，结果压测下来确实快 22ms。我信了。但我到现在都拿不准，他那串 sha256.Sum256 是不是真比 jwt-go 的 reflect 便宜，还是 just placebo —— 人一焦虑，就爱给数字找意义。

　　上次跟 SEO 吵那一架，起因是他要把首页推荐接口加个 AB 测试埋点，要求每个返回加个 trace_id 字段，走同一个 middleware 注入。我当场说不行，他愣了三秒说“你们后台连个 UUID 都生成不了？” 我没理他，转头在 config.yaml 里写了 trace_id_disabled: true。不是硬扛，是那天上午刚修完一个 context cancel 导致的 goroutine 积压，我不想再让任何新字段触发 unknown read-after-cancel。后来他们自己用 nginx upstream 把 trace_id 补上了——挺好，至少说明，有些优化根本不用动 Go 代码，只要别把所有事都当 Go 的问题就行。

　　昨天午饭吃的是饺子，韭菜鸡蛋馅，咸了。旁边工位王姐一边嚼一边说她们栏目最近发稿节奏乱了，因为 CMS 审核页加载要 6 秒，前端用的 antd table 套了七八层高阶组件，每切一页 tab 就重新 fetch 一遍全量数据。我点头，心里想：这跟我管的 /api/v2/audit/status 返回 4.2MB JSON 是同一个病因——都懒得看 schema，更懒得拆分 DTO。但我不接话，怕一开口又变成“你们前端也该学学逃逸分析”。

文章配图，仅供参考

　　考勤系统今天弹窗提示我打卡超时 7 分钟，我划掉，没补。反正月底自动同步，HR 不看实时。就像我们从不监控某个接口的 p999 延迟，只盯着 p95，因为“真实用户根本等不到那幺半天”。这话我信，但去年 11 月有批老年用户投诉说刷新五次才加载成功，后来查出来是某台 LB 的 keepalive 时间设成了 60s，而他们用的定制 ROM 浏览器会复用 TCP 连接但 timeout 写死 45s——于是第 46 秒发的请求永远卡在连接池里。这事没上复盘会，因为太细了，细到没人愿意记在 wiki 里。但它确实让 QPS 翻倍了，至少对我们那条灰度流量线来说是这样。

　　群里谁发了张截图，是线上错误日志里一行 panic: runtime error: invalid memory address or nil pointer dereference，堆栈底下居然带了个 /v2/recommend 的 handler。我扫了眼就划走了——不是不修，是知道它肯定出在某个被注释掉一半的 fallback 逻辑里，而那段代码三年前就没人碰过。我懒得翻 git blame，先发版再说。明天还得接着发，后天还要压测新上线的预加载兜底策略，具体咋兜？还没定，可能用 channel select，也可能直接 time.After —— 看我早上心情。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!