为何仍需通过ServicePointManager.DefaultConnectionLimit配置最大HTTP连接数？

1. ServicePointManager确实是遗留机制 #

ServicePointManager.DefaultConnectionLimit是.NET Framework时代的产物，当时HttpClient的底层依赖ServicePoint组件管理连接池——每个目标主机对应一个全局的ServicePoint实例，连接限制是按主机全局生效的，而非针对单个HttpClient实例。这种设计在当年是为了避免不同HttpClient实例对同一主机创建过多重复连接，但放到如今依赖注入（DI）普及、需要精细化配置的场景下，确实显得陈旧且不够灵活。

2. 单个HttpClient可以设置独立连接限制（你可能没用到正确的方式） #

现代.NET（Core/.NET 5+）已经提供了更灵活的方案：使用SocketsHttpHandler替代旧的HttpClientHandler，它支持为每个Handler实例单独配置MaxConnectionsPerServer属性，从而实现单个HttpClient的连接限制。

在DI系统中，你可以为不同的HttpClient实例配置不同的连接数，示例代码如下：

// 注册第一个HttpClient，限制并发连接数为5
services.AddHttpClient("LowLimitApiClient")
    .ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler
    {
        MaxConnectionsPerServer = 5
    });

// 注册第二个HttpClient，限制并发连接数为20
services.AddHttpClient("HighLimitApiClient")
    .ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler
    {
        MaxConnectionsPerServer = 20
    });

这样，当你通过DI获取命名HttpClient时，它们各自的连接池会遵循独立的限制，完全不需要依赖ServicePointManager的全局配置。

3. 集中式配置的技术合理性（仅存在于旧场景） #

ServicePointManager的集中式设计在.NET Framework时代有其合理性：当时的连接池是全局共享的，按主机维度管理连接可以最大化连接复用，减少系统资源消耗。但随着.NET生态的演进，这种全局配置的局限性越来越明显——无法满足多服务、多场景下的差异化需求。

现在它的存在主要是为了兼容遗留代码，如果你在现代.NET项目中还需要用到它，大概率是因为代码中仍在使用旧的HttpClientHandler（而非默认的SocketsHttpHandler），或者依赖了某些基于旧机制的第三方库。

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