使用IoC管理Flurl/HttpClient时并发请求引发内存异常问题

• 生命周期配置错误：Flurl的FlurlClient是线程安全且设计为可复用的组件。如果在IoC容器中错误地将其配置为**瞬态（Transient）**生命周期，每一次上传请求都会创建全新的FlurlClient实例——每个实例都会初始化独立的HTTP连接池、HttpClientHandler等资源。当并发数达到30时，系统瞬间会生成大量资源对象，频繁的创建与销毁操作直接导致CPU和内存占用急剧飙升。而直接使用new Url()时，Flurl内部会自动复用全局的FlurlClient实例，共享连接池资源，避免了重复创建的开销。

• 连接池与TCP端口耗尽：若IoC中将FlurlClient配置为**范围（Scoped）**生命周期，每个Web API请求都会对应一个独立的FlurlClient实例。30个并发请求就会同时存在30个独立的连接池，这会快速耗尽系统的TCP端口资源，新的连接请求需要等待端口释放，进而引发请求排队。CPU会因为频繁的上下文切换和端口管理操作持续波动，内存也会因堆积的连接对象、请求队列暴涨，最终导致应用挂起。而Flurl默认的全局实例会复用连接池，遵循HTTP连接复用机制，不会出现端口耗尽的问题。

• 缺少合理的连接数限制配置：显式管理Flurl实例时，若未为FlurlClient配置MaxConnectionsPerServer这类关键参数，每个实例会独立维护自己的连接数限制，导致整体连接数远超系统承载能力，引发严重的资源竞争和请求阻塞。直接使用new Url()时，Flurl会采用默认的全局配置，自动将连接数控制在合理范围内，避免了过度竞争的情况。

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