正确做法是用 SendAsync 获取响应流后分块读取并累加字节数计算进度；需用临时文件+原子重命名写入磁盘；UI 更新须用 Progress 自动封送回主线程。
HttpClient.DownloadAsync 怎么带进度回调
原生 HttpClient 的 GetByteArrayAsync 或 GetStreamAsync 都不提供内置进度通知，必须手动分块读取响应流。直接调用 DownloadAsync（.NET 5+）也不行——它根本不存在，这是常见误解。
正确做法是用 SendAsync 发起请求，拿到 HttpResponseMessage 后检查 ContentLength，再用 HttpContent.ReadAsStreamAsync() 获取响应流，最后用循环 + Stream.ReadAsync 分批读取，并在每次读取后累加已读字节数来算百分比。
-
ContentLength可能为null（如服务端没返回Content-Length头），此时无法预估总大小，进度条只能显示“正在下载”或用不确定模式 - 务必设置
HttpRequestMessage.Headers.Accept和HttpClient.Timeout，否则大文件容易超时或被服务端拒绝 - 不要用
response.Content.ReadAsByteArrayAsync()—— 它会把整个文件加载进内存，100MB 文件就占 100MB RAM
怎么安全地写入文件并避免覆盖或中断损坏
边下载边写入磁盘是最常用方式，但直接 FileStream.Write 到目标路径有风险：下载失败会导致文件不完整，重试时又可能覆盖旧文件。
推荐用临时文件 + 原子重命名：
- 下载时写入
"{filename}.tmp"临时路径 - 下载完成且校验（如 MD5/SHA256 可选）通过后，再用
File.Move替换目标文件 - 临时文件和目标文件必须在同一个卷（否则
Move会变成复制+删除，失去原子性） - 写入时用
FileOptions.Asynchronous | FileOptions.SequentialScan提升大文件 I/O 效率
UI 线程更新进度为什么卡死或报“调用线程无法访问”
在 WinForms 或 WPF 中，从 async 方法里直接更新 ProgressBar.Value 或 Label.Text 会抛 InvalidOperationException，因为回调发生在 ThreadPool 线程，而非 UI 线程。
不能靠 Control.Invoke 手动切回——太繁琐还易漏；推荐用 Progress：
- 构造
new Progress(value => progressBar.Value = value) - 在下载循环中调用
progress.Report(percentage) -
Progress内部自动封送回原始同步上下文（即 UI 线程） - 注意：WPF 中需确保创建
Progress实例时处于 UI 线程，否则仍可能出错
为什么下载速度忽高忽低甚至卡住几秒
不是代码问题，大概率是默认的 HttpClient 连接复用策略和 DNS 缓存导致的。特别是跨域、CDN 或 HTTP/2 场景下：
- 启用
HttpCompletionOption.ResponseHeadersRead，避免等待整个响应体就提前拿到头信息 - 设置
HttpClient.DefaultRequestHeaders.UserAgent，某些 CDN 对无 UA 的请求限速或延迟响应 - 禁用 DNS 缓存：
ServicePointManager.DnsRefreshTimeout = 0（谨慎使用，影响全局） - 如果目标是 HTTPS，确认服务端支持 HTTP/2 —— .NET Core 3.1+ 默认启用，但部分老旧服务器握手慢，可临时降级到 HTTP/1.1：
new HttpClientHandler { SslProtocols = SslProtocols.Tls12 }
进度计算本身很简单，难点在流控制、异常恢复和资源清理：Stream 必须 Dispose，HttpClient 实例建议复用，临时文件失败时要主动清理。这些细节不处理，跑几天就出问题。
