为何Go语言中用Go Routine发起HTTP请求单请求耗时更长？

你观察到的现象本质是并发场景下的额外开销与同步场景的连接复用优化共同作用的结果，具体原因可以拆解为以下几点：

• TCP连接复用的差异
  Go标准库的net/http客户端默认开启了HTTP keep-alive机制。同步请求时，第一个请求需要完成TCP三次握手来建立连接，耗时稍高；后续请求直接复用已建立的长连接，省去了连接建立的完整开销，所以单个请求耗时明显缩短。而并发请求几乎同时发起，此时没有可用的已建立连接，大部分请求需要新建TCP连接（受限于客户端连接池初始大小），每个请求的耗时包含了连接建立的全部成本，因此单个请求耗时比同步复用连接的请求更长。

• goroutine调度与资源竞争的额外开销
  并发场景下，多个goroutine会同时向Go调度器申请执行时间，不可避免会产生goroutine上下文切换的开销。同时，内核层面需要处理多个并发的网络请求，涉及套接字创建、端口分配、网络队列调度等资源竞争，这些额外的开销都会被计入单个请求的耗时中，导致其比串行执行的请求耗时增加。

• 服务端并发处理的开销
  同步请求是串行到达服务端，服务端每次只处理一个请求，CPU和内存的调度压力极小，响应速度快。而并发请求同时到达时，服务端需要同时处理多个请求，会产生更多的上下文切换开销，单个请求的处理时间会被拉长——哪怕是本地运行的简易服务，也无法完全避免这种并发处理带来的额外耗时。

• 计时逻辑的偏差
  在并发场景下，goroutine可能会因为调度策略被暂时挂起，这段等待调度的时间也会被计入请求的总耗时。而同步请求是连续执行的，goroutine不会被频繁调度挂起，计时结果更贴近请求的实际网络和处理时间。

补充说明 #

虽然单个并发请求的耗时更长，但总耗时远低于同步请求，这正是并发的核心优势：通过并行利用网络等待时间和系统资源，提升了整体的吞吐量和效率。同步请求的单个耗时短只是因为复用了连接，但其总耗时是多个请求的时间累加，整体效率远不如并发模式。

内容的提问来源于stack exchange，提问作者leonard adi