垂直搜索引擎高并发长连接服务的关键在于连接生命周期、请求上下文与资源回收三者对齐；需禁用http.DefaultClient，自定义http.Client并调优参数，分层限流，并严格同步context生命周期与资源释放。
Go 语言做垂直搜索引擎的高并发长连接服务，关键不在“压测能到多少 QPS”，而在连接生命周期、请求上下文、资源回收三者是否对齐。用错 http.DefaultClient 或漏关 resp.Body，50 个并发就能触发 too many open files；不设 IdleTimeout，长连接堆积会让 goroutine 数持续上涨，pprof 里一眼看到几千个卡在 readRequest。
为什么 http.DefaultClient 在搜索场景下会崩
垂直搜索引擎通常要高频调用内部微服务（如索引服务、排序服务、NER 服务），而 http.DefaultClient 的 Transport 默认配置是为通用低频请求设计的：
-
MaxIdleConnsPerHost = 2：单个后端服务（比如http://ranker:8080）最多只缓 2 个空闲连接，100 路并行打过去，98 个在排队等连接 -
IdleConnTimeout = 30s：连接空闲超 30 秒就被回收，但搜索请求常有长尾（比如聚合计算、向量召回），刚建好连接又得重连 - 没设
Client.Timeout：某个排序服务卡住，整个 goroutine 就挂起，不释放连接也不退出
结果不是慢，而是请求开始批量失败，错误日志里反复出现 net/http: request canceled (Client.Timeout exceeded) 或直接 dial tcp: i/o timeout。
必须自定义 http.Client 并调参
所有对外 HTTP 调用（包括搜索网关调索引、调排序、调缓存代理）都应复用同一个带调优参数的 http.Client 实例，而不是每次 new 一个。
立即学习“go语言免费学习笔记（深入）”；
典型配置（适配中等规模垂直搜索集群）：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 2000,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 90 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
},
Timeout: 8 * time.Second,
}说明：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
MaxIdleConnsPerHost = 200是硬门槛——假设你有 5 个后端服务，每个最多撑住 200 并发连接，才不会因单点阻塞拖垮整条链路 -
IdleConnTimeout = 90s要比你最长搜索路径的 P99 延迟略高（比如实测排序 P99 是 6.2s，那就设 90s 安全） - 禁用
http.DefaultClient，哪怕只有一处用了它，就可能成为连接泄漏的突破口
goroutine 不是越多越好，要配信号量控并发
搜索请求本身是组合式调用：查倒排 → 取 doc → 排序 → 打分 → 聚合 → 渲染。每一步若都无约束并发，很容易在中间层（比如向量相似度服务）打出雪崩。
正确做法是分层限流：
- 入口层用
golang.org/x/sync/semaphore控制总并发数（例如sem := semaphore.NewWeighted(50)） - 下游服务调用时，按 SLA 分级申请权重：索引服务权重大（1）、排序服务权重中（3）、NER 服务权重小（0.5）
- 每个 handler 内部禁止裸写
go doXXX()，所有 goroutine 启动前必须sem.Acquire(ctx, weight)
漏掉 Acquire 或没 Release，轻则 goroutine 泄漏，重则整个搜索节点被系统 OOM kill。
长连接 ≠ 永远不关，必须对齐 context 生命周期
垂直搜索里常见「用户输入未完成就删字」或「页面切走」，这时上游已取消，但下游 HTTP 请求还在跑，连接占着、goroutine 卡着、内存不释放。
必须做到三点同步：
- 所有
http.NewRequestWithContext都传入从http.Request.Context()衍生的子 context - 下游服务返回
resp后，立刻defer resp.Body.Close()—— 即使err != nil也得判空再关 - 若使用自定义
net.Conn（比如直连向量库 gRPC 或 Redis），需在conn.Read和conn.Write时显式检查ctx.Err()
最容易忽略的是：HTTP/2 流复用下，一个 TCP 连接承载多个逻辑请求，Body.Close() 不只是释放响应体，更是告诉 Transport “这个流可以回收了”。漏关一次，整个连接池就少一个可用 slot。
