为何新开发不推荐使用ServicePointManager？证书校验方案对比

HttpClientHandler.ServerCertificateValidationCallback 方案优势 #

• 作用域完全隔离：回调是绑定到单个HttpClientHandler实例的，只会影响通过该handler创建的HttpClient发出的请求，不会干扰应用内其他HTTP请求的默认校验逻辑，完全避免多模块自定义规则互相冲突的问题，尤其适合集成了多套第三方SDK的项目。
• 无逻辑残留风险：回调生命周期和所属的HttpClientHandler完全一致，如果是临时需要自定义校验规则（比如调试阶段对接自签名证书的测试环境），用完直接释放对应handler即可让校验规则失效，不需要手动重置全局配置，不会出现测试规则漏删带到生产的问题。
• 细粒度控制能力更强：回调参数中携带的HttpRequestMessage包含当前请求的完整上下文，包括请求地址、请求头、自定义传递的业务属性等，可以很方便地实现“仅对特定域名/特定场景的请求自定义校验，其余请求走系统默认安全校验”的规则，不需要额外做全局请求匹配。
• 全平台兼容：这套API在.NET Framework、.NET Core/.NET 5+全版本栈中行为一致，后续如果做跨版本框架迁移，这部分逻辑不需要做任何修改，没有兼容包袱。
• 不存在逻辑覆盖问题：因为是实例级配置，不同模块的自定义校验规则完全独立，不会出现后加载的模块直接覆盖其他模块校验逻辑的问题。

ServicePointManager.ServerCertificateValidationCallback 方案的适用场景（仅存的优势） #

• 覆盖老HTTP栈请求：这个回调是进程全局级的，除了HttpClient的请求之外，还能拦截到老的HttpWebRequest、WebClient以及基于这些老实现封装的第三方组件发出的HTTPS请求，如果项目里存在大量未改造的历史HTTP调用代码，只有这个配置能统一接管所有请求的证书校验流程。
• 历史项目改造成本低：如果是年代久远的老项目，HTTP调用零散分布在各个业务模块，没有做统一的HTTP客户端封装，只需要在应用启动入口加一行全局配置，就能给所有走老HTTP栈的请求加上自定义校验逻辑，不需要逐个修改请求初始化代码。

微软官方文档明确给出提示：

我们不建议你在新开发工作中使用ServicePointManager类，应改用System.Net.Http.HttpClient类。

除了跨版本兼容问题之外，核心原因还有以下几点：

• 全局状态风险极高：ServicePointManager是进程域内的全局静态对象，上面的所有配置（包括证书校验回调、TLS版本、连接限制等）一旦修改，会影响整个应用内所有走老HTTP栈的请求，包括第三方SDK内部的隐式HTTP调用。最常见的坑就是开发为了对接测试环境给回调写了“永远返回true”的逻辑，漏改上线后导致全应用所有HTTPS请求跳过证书校验，存在严重的中间人攻击风险。
• 回调逻辑会被意外覆盖：ServerCertificateValidationCallback是静态委托，对它的赋值是覆盖而非追加，如果多个模块、多个第三方SDK都尝试修改这个回调，后赋值的逻辑会直接替换掉之前的逻辑，既可能导致你写的校验规则不生效，也可能在你不知情的情况下把其他模块的安全校验逻辑替换掉，问题排查难度极高。
• 连接管理能力落后：ServicePointManager的连接池是按域名做粗粒度管理的，连接复用效率低、配置灵活性差，高并发场景下很容易出现连接耗尽、请求排队、连接泄漏的问题；而HttpClient栈的连接池和handler绑定，支持细粒度的连接生命周期管理、空闲连接回收、超时配置，高并发下的性能和稳定性远优于老的ServicePointManager实现。
• 配置粒度过粗：所有配置都是全局生效，无法针对不同的目标服务、不同的请求做差异化配置——比如你没法单独给A服务配置TLS1.3、给B服务放开自签名证书校验，所有规则只能全局统一，完全无法适配现在多服务、多第三方接口对接的复杂业务场景。
• 已停止功能迭代：从.NET Framework 4.5开始，微软就没有再给ServicePointManager新增过任何功能，后续的HTTP栈性能优化、新安全协议支持（比如TLS 1.3）、新扩展能力全部是在HttpClient栈上落地的，ServicePointManager目前仅做兼容性维护，不会再有新的能力更新。

实际开发建议：只要是新编写的代码，无论运行在.NET Framework还是新版本.NET平台，都优先使用HttpClient+HttpClientHandler的方式实现自定义证书校验；ServicePointManager的全局配置仅建议用来兼容无法改造的老HttpWebRequest/WebClient遗留代码，不要在新逻辑中依赖。

内容的提问来源于stack exchange，提问作者Gal I.