net/http默认配置因保守的连接池参数易成吞吐瓶颈，需调优maxidleconns等参数；fasthttp虽吞吐高但不兼容http/2和中间件生态，适用场景有限；bufio缓冲可降系统调用频次，但需匹配协议特性。
为什么 net/http 默认配置会成为吞吐瓶颈
Go 的 http.Server 默认启用了连接复用（keep-alive）和长连接，但默认的 MaxIdleConns、MaxIdleConnsPerHost 和 IdleConnTimeout 都偏保守。在高并发短连接或大量后端调用场景下，你可能看到大量 http: TLS handshake timeout 或 http: server gave HTTP response to HTTPS client 类似错误——其实根本不是 TLS 问题，而是连接池耗尽或过早关闭导致重试堆积。
实操建议：
- 显式配置
http.Transport：把MaxIdleConns设为200或更高，MaxIdleConnsPerHost至少匹配后端实例数，IdleConnTimeout建议设为30 * time.Second（太长易占资源，太短频繁重建） - 禁用
ExpectContinueTimeout（设为 0），避免小请求卡在 100-continue 等待上 - 若用
http.Client调用外部服务，务必复用单例，不要每次 new
什么时候该换 fasthttp，又为什么不能盲目换
fasthttp 在纯吞吐指标上常比 net/http 高 2–5 倍，核心是绕过了 net/http 的标准 Request/Response 对象分配和反射解析。但它不兼容 http.Handler 接口，也不支持 HTTP/2、Streaming Response 等特性。
适用场景很明确：
- 内部 RPC 网关、反向代理、静态文件转发等协议简单、路径固定、无需中间件生态的场景
- 压测时发现
net/http的 GC 压力集中在http.Header和bytes.Buffer分配上（pprof 查runtime.mallocgc占比 >40%）
踩坑提醒：
