因为似乎还没有人在这里提到它，在。net Core >=2.1和。net 5.0+中管理HttpClient和HttpClientHandler的最佳新方法是使用HttpClientFactory。

它以一种干净和易于使用的方式解决了上述大多数问题和陷阱。摘自Steve Gordon的博客文章:

将以下包添加到.Net Core(2.1.1或更高版本)项目中:

Microsoft.AspNetCore.All
Microsoft.Extensions.Http

将此添加到Startup.cs:

services.AddHttpClient();

注射使用:

[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly IHttpClientFactory _httpClientFactory;

    public ValuesController(IHttpClientFactory httpClientFactory)
    {
        _httpClientFactory = httpClientFactory;
    }

    [HttpGet]
    public async Task<ActionResult> Get()
    {
        var client = _httpClientFactory.CreateClient();
        var result = await client.GetStringAsync("http://www.google.com");
        return Ok(result);
    }
}

探索Steve博客中的系列文章，了解更多功能。

我认为应该使用单例模式来避免创建HttpClient实例并一直关闭它。如果你使用的是。net 4.0，你可以使用下面的示例代码。有关单例模式检查的更多信息，请点击这里。

class HttpClientSingletonWrapper : HttpClient
{
    private static readonly Lazy<HttpClientSingletonWrapper> Lazy= new Lazy<HttpClientSingletonWrapper>(()=>new HttpClientSingletonWrapper()); 

    public static HttpClientSingletonWrapper Instance {get { return Lazy.Value; }}

    private HttpClientSingletonWrapper()
    {
    }
}

使用下面的代码。

var client = HttpClientSingletonWrapper.Instance;

在我的例子中，我在一个实际执行服务调用的方法中创建了一个HttpClient。喜欢的东西:

public void DoServiceCall() {
  var client = new HttpClient();
  await client.PostAsync();
}

在Azure工作人员角色中，在反复调用该方法之后(没有处理HttpClient)，它最终会以SocketException失败(连接尝试失败)。

我使HttpClient成为一个实例变量(在类级别上处理它)，这个问题就消失了。所以我会说，是的，释放HttpClient，假设它是安全的(你没有未完成的异步调用)。

因为似乎还没有人在这里提到它，在。net Core >=2.1和。net 5.0+中管理HttpClient和HttpClientHandler的最佳新方法是使用HttpClientFactory。

它以一种干净和易于使用的方式解决了上述大多数问题和陷阱。摘自Steve Gordon的博客文章:

将以下包添加到.Net Core(2.1.1或更高版本)项目中:

Microsoft.AspNetCore.All
Microsoft.Extensions.Http

将此添加到Startup.cs:

services.AddHttpClient();

注射使用:

[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly IHttpClientFactory _httpClientFactory;

    public ValuesController(IHttpClientFactory httpClientFactory)
    {
        _httpClientFactory = httpClientFactory;
    }

    [HttpGet]
    public async Task<ActionResult> Get()
    {
        var client = _httpClientFactory.CreateClient();
        var result = await client.GetStringAsync("http://www.google.com");
        return Ok(result);
    }
}

探索Steve博客中的系列文章，了解更多功能。

在我的理解中，只有当Dispose()锁定稍后需要的资源(如特定连接)时才有必要调用Dispose()。总是建议释放你不再使用的资源，即使你不再需要它们，只是因为你通常不应该持有你不使用的资源。

微软的例子不一定是错误的。当应用程序退出时，将释放所使用的所有资源。在那个例子中，它几乎是在HttpClient被使用完之后立即发生的。在类似的情况下，显式调用Dispose()有点多余。

但是，一般来说，当一个类实现IDisposable时，只要您完全准备好并能够执行，您就应该Dispose()它的实例。我认为在像HttpClient这样的情况下尤其如此，其中没有明确地记录资源或连接是否被保持/打开。在连接将[很快]再次被重用的情况下，您将希望放弃它的dispose()处理——在这种情况下，您还没有“完全准备好”。

参见: IDisposable。Dispose方法和何时调用Dispose

目前的答案有点令人困惑和误导，它们遗漏了一些重要的DNS含义。我会试着把情况总结清楚。

Generally speaking most IDisposable objects should ideally be disposed when you are done with them, especially those that own Named/shared OS resources. HttpClient is no exception, since as Darrel Miller points out it allocates cancellation tokens, and request/response bodies can be unmanaged streams. However, the best practice for HttpClient says you should create one instance and reuse it as much as possible (using its thread-safe members in multi-threaded scenarios). Therefore, in most scenarios you'll never dispose of it simply because you will be needing it all the time. The problem with re-using the same HttpClient "forever" is that the underlying HTTP connection might remain open against the originally DNS-resolved IP, regardless of DNS changes. This can be an issue in scenarios like blue/green deployment and DNS-based failover. There are various approaches for dealing with this issue, the most reliable one involving the server sending out a Connection:close header after DNS changes take place. Another possibility involves recycling the HttpClient on the client side, either periodically or via some mechanism that learns about the DNS change. See https://github.com/dotnet/corefx/issues/11224 for more information (I suggest reading it carefully before blindly using the code suggested in the linked blog post).