应避免在UI线程调用WebClient.DownloadFile，改用DownloadFileAsync或HttpClient+流式下载；需设置User-Agent防403；下载前清理旧文件；HttpClient推荐结合Polly重试。

WebClient.DownloadFile 会阻塞线程，别在 UI 线程直接调用

WebClient 的 DownloadFile 是同步方法，调用时当前线程会一直等待直到下载完成或失败。在 WinForms 或 WPF 的主线程里直接用，界面立刻卡死。

实操建议：

• 改用 DownloadFileAsync，配合 DownloadProgressChanged 和 DownloadFileCompleted 事件更新进度和处理结果
• 如果用的是 .NET Core / .NET 5+，优先转向 HttpClient + GetStreamAsync 配合 FileStream 流式写入，更可控且默认异步
• 注意 DownloadFileAsync 不支持取消，如需中途停止，得换 HttpClient + CancellationToken

HttpClient 下载大文件必须流式处理，不能用 GetStringAsync

GetStringAsync 会把整个响应体读进内存再转成字符串，下载几 MB 的 PDF 或 ZIP 就可能触发 OutOfMemoryException，尤其在低内存设备上。

正确做法是用流：

• 调用 GetStreamAsync 获取响应流，而不是读取全部内容
• 用 FileStream（设置 FileOptions.Asynchronous）或 FileStream.WriteAsync 写入磁盘
• 务必用 using 或 await using 确保流及时释放，否则文件句柄泄漏、磁盘写入不完整

示例关键片段：

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

using var response = await client.GetAsync(url, cancellationToken);
using var streamToRead = await response.Content.ReadAsStreamAsync();
using var streamToWrite = new FileStream(filePath, FileMode.Create, FileAccess.Write, FileShare.None, 8192, FileOptions.Asynchronous);
await streamToRead.CopyToAsync(streamToWrite, cancellationToken);

WebClient 默认不带 User-Agent，部分网站会 403 拒绝

很多 CDN 或反爬站点检查 User-Agent 请求头，WebClient 默认不发送，直接返回 403。这不是权限问题，是服务端主动拦截。

解决方式：

• 给 WebClient.Headers 显式添加：client.Headers[HttpRequestHeader.UserAgent] = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
• HttpClient 则通过 DefaultRequestHeaders.UserAgent.ParseAdd(...) 设置
• 注意某些站点还校验 Accept 或 Referer，遇到 403 时用浏览器开发者工具比对请求头

下载中断或网络异常时，临时文件没清理干净

无论是 WebClient.DownloadFileAsync 还是手写的 HttpClient 流写入，一旦中途出错（如断网、服务器关闭连接），目标路径可能残留一个不完整的文件。下次再下载同名文件，不会自动覆盖，而是直接写入——导致文件损坏却无提示。

安全做法：

• 下载前先检查目标路径是否存在，存在则 File.Delete（确保有权限）
• 或改用临时文件名下载，成功后再 File.Move 覆盖，利用原子操作避免脏数据暴露
• WebClient 没内置重试，HttpClient 可配合 Polly 实现带退避的重试逻辑，但注意幂等性：GET 一般安全，POST 不适用

临时文件残留不是小问题，它会让后续「文件存在判断」逻辑失效，尤其是自动更新场景下静默出错最难排查。