Go

«结论先行："ReadTimeout" / "WriteTimeout" / "IdleTimeout" 三者管的不是"一次请求的总耗时"，而是三件完全不同的事；把它们当"接口超时"来配，是 Go 服务里最容易埋雷的一个配置位。本文把三个超

【背景】 我在做一个 3 年经验的性能优化，最近帮一个内部团队复盘一个 Go 1.21 网关服务：4C8G 单实例，QPS 约 4k，链路是「网关 → MySQL（读写分离）+ Redis」。P50 稳定在 25ms，P95 在 60ms

【背景】 我在给一套内部服务做安全加固，目标是"证书 90 天强制轮换 + 轮换期间业务无感"。栈是 Go 1.22 + gRPC，跑在 3 节点自建 K8s 1.28，没有 Istio，mTLS 由应用层自己用 crypto/tls 的

背景 15 年嵌入式出身，现在带一个 Go 1.22 的数据清洗服务（K8s 1.28.6 / containerd 1.7.13 / cgroup v2 / 内核 5.15，节点 16C64G）。服务每天凌晨跑批，从 NFS 拉一份 1.

【背景】 我做了 8 年性能优化，最近带团队复盘一个 Go 1.22 的网关服务：单实例 8C16G，QPS 约 1.2w，请求体平均 8KB 左右，主要开销在 JSON 编解码 + 下游 HTTP 调用。P50 稳定在 18ms，但 P9

一、现象：一次「无变更」引发的雪崩 上个月我们对一套日均 42 亿次 RPC 调用的支付中台做稳定性复盘。某次大促前夜压测，入口网关 QPS 从 8k 拉到 12k（仅 +50%），下游 47 个服务的 Go 线程池（GOMAXPROCS=

一、现象：一个「看起来随机」的 8 位重置 token，被 208 次请求还原了 去年给一家电商客户做安全加固复盘，目标是「找回密码」接口：用户填邮箱，后端生成一个 8 位 token 写进数据库、拼进重置链接 "https://reset

«结论先行：gRPC 的 server-streaming 接口，OOM 和 goroutine 泄漏的根因几乎都不是"发不出去"，而是"服务端在内存里预生成了全量数据"，以及"客户端取消后服务端 goroutine 没感知到、继续空跑"。

背景 我负责一个 Go 1.22 写的订单网关，部署在 K8s 1.28（containerd 1.7，节点 16C64G）。QPS 峰值 ~3k，单副本。最近一个月被 OOMKilled 3 次，每次都在流量高峰 1~2 小时内，重启后又

一、现象：一条「图片预览」接口，把内网扫了个遍 去年给一家做 SaaS 的客户做渗透评估，目标是一套 Go（Gin 1.9）+ 云上的「文档图片代理预览」接口 "GET /api/img/preview?url=..."——前端把外链图片地

背景 10 年 SRE，最近接手一个 K8s 1.28（containerd 1.7，节点 16C64G）上的 Go 1.21 网关服务，4 副本、单副本峰值 QPS 约 2k，主要工作是转发 + 一些带 30~60s 长连接的任务。 现象