WebClient将非2xx状态码视为异常抛出，而HttpClient将其作为响应正常部分处理；2. HttpClient通过IsSuccessStatusCode判断业务逻辑，仅在底层通信失败时抛出HttpRequestException；3. HttpClient设计更符合现代API交互需求，代码结构清晰且灵活；4. 实际开发中可结合try-catch处理网络异常，并根据StatusCode执行相应业务逻辑；5. WebClient因异步支持弱、配置受限、异常处理不灵活，在现代C#应用中已基本被HttpClient取代。
C#中WebClient和HttpClient在异常处理上的核心区别在于它们如何看待并处理HTTP状态码（例如404、500等）。简单来说，WebClient会将这些非成功的HTTP状态码视为一种异常（WebException）抛出，而HttpClient则认为它们是HTTP响应的正常组成部分，并不会默认抛出异常，而是通过检查响应对象的属性来判断请求是否成功。只有当HttpClient遇到网络连接问题、DNS解析失败等底层通信错误时，才会抛出HttpRequestException。
在深入探讨这个问题时，我常常会想，这两种设计哲学背后，其实反映了对“异常”这个概念的不同理解。WebClient的设计思路更像是“凡是不符合2xx成功的，都是异常，需要我捕获来处理”。而HttpClient则更现代，它认为像404资源未找到，或者401未授权，这些都是API交互中可能预期的结果，它们本身并不是“程序崩溃”或“网络断开”那种意义上的异常，而是业务逻辑需要判断和处理的“非成功响应”。
HttpClient处理HTTP错误码的方式为何更受青睐？
在我看来，HttpClient这种处理HTTP错误码的方式，是现代Web API交互的必然趋势，也因此更受开发者青睐。说白了，HTTP协议本身就定义了各种状态码来表达请求的结果，比如2xx表示成功，3xx表示重定向，4xx表示客户端错误，5xx表示服务器错误。这些状态码是协议的一部分，是服务器明确告诉客户端“我收到了你的请求，这是处理结果”的方式。
WebClient把所有非2xx的状态码都一股脑地扔进
WebException里，这固然简单粗暴，但有时候会显得不够灵活。比如，你请求一个用户头像，如果返回404，你可能只是想显示一个默认头像，而不是让整个程序因为一个“异常”而中断。或者，当用户登录失败，服务器返回401，这并不是一个程序错误，而是业务逻辑上的“用户名或密码错误”，你只需要提示用户重新输入即可。如果每次都要捕获
WebException，然后解析其内部的
HttpWebResponse来判断状态码，代码会显得有点儿啰嗦，而且把业务逻辑的判断混杂在异常处理中，总觉得不是那么优雅。
HttpClient的设计则更符合这种“HTTP状态码是响应的一部分”的理念。它把网络连接断开、DNS解析失败这种真正的底层通信问题定义为
HttpRequestException，因为这些确实是程序无法继续执行的“异常”情况。而对于HTTP状态码，它提供了一个
IsSuccessStatusCode属性，以及
StatusCode枚举，让你能够非常直观地检查响应结果。你可以在接收到响应后，根据
StatusCode的值来决定下一步的业务逻辑，而不是被迫进入一个
catch块。这种模式让代码结构更清晰，业务逻辑和错误处理能够更好地分离。
在实际项目中，如何优雅地处理HttpClient的异常与非成功响应？
在实际开发中，利用HttpClient的特性来优雅地处理异常和非成功响应，是提升代码健y健壮性和可读性的关键。我的做法通常是这样的：
首先，我会用一个
try-catch块来包裹HttpClient的调用，但这个
catch主要是为了捕获
HttpRequestException。因为
HttpRequestException通常意味着网络层面的问题，比如服务器宕机、DNS解析失败、连接超时等，这些是真正的“异常”，往往需要记录日志、提示用户网络问题，甚至触发重试机制。
using System.Net.Http;
using System.Threading.Tasks;
using System;
public class ApiClient
{
private readonly HttpClient _httpClient;
public ApiClient(HttpClient httpClient)
{
_httpClient = httpClient ?? throw new ArgumentNullException(nameof(httpClient));
}
public async Task GetDataAsync(string url)
{
try
{
var response = await _httpClient.GetAsync(url);
// 检查HTTP状态码是否成功
if (response.IsSuccessStatusCode)
{
return await response.Content.ReadAsStringAsync();
}
else
{
// 处理非成功的HTTP状态码
Console.WriteLine($"HTTP Request Failed: {response.StatusCode}");
var errorContent = await response.Content.ReadAsStringAsync();
Console.WriteLine($"Error Details: {errorContent}");
// 根据具体状态码进行业务逻辑处理
if (response.StatusCode == System.Net.HttpStatusCode.NotFound)
{
// 资源不存在，可能返回空或特定默认值
return "Resource Not Found";
}
else if (response.StatusCode == System.Net.HttpStatusCode.Unauthorized)
{
// 未授权，可能需要刷新Token或重新登录
Console.WriteLine("Authentication required.");
// throw new UnauthorizedAccessException("User is not authorized."); // 或者抛出自定义业务异常
return "Unauthorized";
}
else
{
// 对于其他非预期的错误，可以考虑抛出HttpRequestException，
// 这样上层调用者可以统一处理所有非2xx的响应
response.EnsureSuccessStatusCode(); // 这行代码会抛出HttpRequestException
return null; // 理论上不会执行到这里
}
}
}
catch (HttpRequestException ex)
{
// 处理网络层面的异常（DNS解析失败、连接超时等）
Console.WriteLine($"Network or HTTP request error: {ex.Message}");
// 可以检查ex.InnerException获取更详细的错误信息
throw; // 重新抛出，让上层知道发生了网络问题
}
catch (Exception ex)
{
// 捕获其他可能的异常，比如内容解析失败等
Console.WriteLine($"An unexpected error occurred: {ex.Message}");
throw;
}
}
} 在上面的例子中，我展示了如何先判断
IsSuccessStatusCode。如果为
false，我会根据具体的
StatusCode进行业务逻辑判断。例如，404可能意味着资源不存在，401意味着需要认证。只有当遇到我确实无法处理，或者认为上层调用者应该统一处理的非成功状态码时，我才会调用
response.EnsureSuccessStatusCode()。这个方法会在
IsSuccessStatusCode为
false时抛出
HttpRequestException，这样就能够把某些特定的HTTP错误“升级”为异常，让它们被上层的
catch (HttpRequestException ex)捕获。这种做法提供了极大的灵活性，既能优雅处理预期内的HTTP错误，又能有效捕获真正的网络异常。
WebClient在现代C#应用中还有用武之地吗？
老实说，在现代C#应用开发中，尤其是在涉及到网络通信和HTTP请求的场景，WebClient的存在感已经非常微弱了。我个人在新的项目里几乎不再使用它。
WebClient是.NET Framework早期提供的一个非常简便的HTTP客户端。它API简单，上手快，对于一些非常基础的、不需要复杂配置的GET或POST请求，比如下载一个文件、上传一段文本，它确实能快速实现。它的同步方法用起来也很直观，一行代码就能完成请求。
然而，它的局限性也非常明显：
-
同步为主，异步支持有限且老旧：虽然有
DownloadStringAsync
这类方法，但它们基于旧的APM（Asynchronous Programming Model）模式，使用Begin/End
模式，不如HttpClient
基于Task-based Asynchronous Pattern (TAP)
的async/await
那么现代和易用。在现代应用中，异步操作是常态，避免阻塞UI线程或服务器线程至关重要。 -
配置和扩展性差：WebClient几乎没有提供对请求/响应管道的细粒度控制。你很难添加自定义的HTTP头（除了少数几个）、配置代理、设置超时时间（虽然可以设置，但不如HttpClient灵活）、处理Cookies、重试策略，更别提自定义消息处理器（Message Handlers）来拦截和修改请求/响应了。而HttpClient则提供了强大的
HttpClientHandler
和DelegatingHandler
机制，可以构建非常复杂的请求管道。 - 异常处理的哲学差异：如前所述，它将所有非2xx状态码都视为异常抛出，这在处理某些HTTP API时并不高效。
-
资源管理：WebClient通常需要在使用完毕后手动调用
Dispose()
，或者使用using
语句。而HttpClient的设计更倾向于复用同一个实例，以优化性能（避免每次请求都建立新的TCP连接）。
所以，WebClient在今天看来，更像是一个历史遗留产物。如果你正在维护一个非常老的项目，或者需要编写一个极其简单的、一次性的脚本，并且对性能、可扩展性、异步编程没有太高要求，WebClient或许还能用。但对于任何新的、需要健壮性、高性能、可维护性、以及能够灵活处理各种HTTP场景的应用，HttpClient无疑是唯一且正确的选择。它的设计理念和功能集都更符合现代Web服务的开发需求。
