go web服务器qps卡在100–200的主因是默认配置与常见写法失配：http.server未设超时、连接池不合理、gomaxprocs与容器资源不匹配、handler隐式阻塞，四者占90%性能损失；需显式配置readtimeout、writetimeout、idletimeout及maxheaderbytes等参数。
go web 服务器的 qps 卡在 100–200，不是语言不行，而是默认配置和常见写法在高并发下迅速暴露瓶颈——http.server 的超时、连接池、gomaxprocs 与容器资源不匹配，以及 handler 中隐式阻塞，这四点占了 90% 的性能损失。
调整 http.Server 超时与连接参数
默认的 http.Server 几乎没设限，压测时大量空闲连接堆积、慢请求拖垮整体吞吐。必须显式控制生命周期：
-
ReadTimeout设为5 * time.Second：防慢客户端长期占着连接 -
WriteTimeout设为10 * time.Second：避免响应生成卡住 goroutine -
IdleTimeout设为60 * time.Second：及时回收 HTTP/1.1 keep-alive 空闲连接 -
MaxHeaderBytes限制在1 （1MB）：防恶意大 header 耗尽内存
漏掉 IdleTimeout 是最常被忽略的点——它不写，连接就永远挂着，netstat -an | grep :8080 | wc -l 很快破千。
HTTP 客户端连接池必须独立配置
如果你的服务要调用其他后端（如 Redis、MySQL、下游 API），千万别用全局默认 http.DefaultClient。它的 Transport 默认只允许 2 个连接到同一 host，QPS 上不去就是卡在这儿：
-
MaxIdleConns至少设为1000（不是 100） -
MaxIdleConnsPerHost必须等于MaxIdleConns，否则单 host 仍被限死在 100 -
IdleConnTimeout设为90 * time.Second，比服务端IdleTimeout略长，避免“服务端已关连接，客户端还傻等”
示例片段：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 1000,
MaxIdleConnsPerHost: 1000,
IdleConnTimeout: 90 * time.Second,
},
Timeout: 30 * time.Second,
}
容器环境下强制对齐 GOMAXPROCS 与 CPU 限额
宿主机 8 核、容器 --cpus=2，但 Go 默认启动 8 个 P，结果 8 个逻辑处理器抢 2 个物理核，上下文切换爆炸——这是云原生部署中最隐蔽的 QPS 折损点：
- 启动前加
os.Setenv("GOMAXPROCS", "2")，或更稳妥地读取/sys/fs/cgroup/cpu/cpu.cfs_quota_us动态计算 - 不要依赖
runtime.GOMAXPROCS(0)，它返回的是宿主机核数，不是容器配额 - 配合
pprof看/debug/pprof/goroutine?debug=2，若大量 goroutine 停在runtime.futex或semacquire，基本就是 P 过多争抢导致
Handler 内禁止隐式阻塞操作
看似简单的 time.Sleep、未设 timeout 的 DB 查询、同步写日志、直接调 http.Get，都会让整个 goroutine 阻塞，而 Go 的 net/http 默认不限制并发 goroutine 数量，一卡全卡：
- 所有外部调用必须带
context.WithTimeout，比如redisClient.Get(ctx, key).Result()的ctx要来自c.Request.Context() - 避免在 handler 里做任何耗时计算；拆成异步任务 + channel 或发到 worker pool
- 日志用结构化异步 logger（如
zerolog配log.Logger.With().Caller().Hook()），别用fmt.Printf或同步log.Println
最容易被忽略的是：即使用了 sync.Pool，如果从 sync.Pool.Get() 拿出来的对象没清空状态，下次复用就会污染数据——这不会降 QPS，但会引发线上诡异 bug。
