分片上传需手动控制HttpClient生命周期，禁用默认超时与响应缓存，逐片构造请求并校验服务端状态，配合客户端本地状态文件实现断点续传。
分片上传必须自己控制 HttpClient 的请求生命周期
默认用 HttpClient.PostAsync() 直接传整个大文件，内存暴涨、超时、OOM 都是必然结果。分片不是“把文件切开再拼”，而是手动拆、逐块发、服务端配合合并——客户端根本不能依赖任何“自动分片”封装。
实操建议：
- 用
FileStream+BufferedStream按固定大小（如 4MB）读取字节块，避免一次性File.ReadAllBytes() - 每片单独构造
HttpContent（推荐ByteArrayContent或StreamContent），设好Content-Range头 - 禁用
HttpClient的默认超时（Timeout = TimeSpan.FromMinutes(10)），并启用MaxResponseContentBufferSize = 0防止响应体缓存吃内存 - 别复用同一个
HttpRequestMessage实例发多片——每次新建，否则 headers 可能污染
HttpClient 连接复用和 DNS 缓存导致上传中途断连
看似稳定的网络，上传到第 5 片突然报 HttpRequestException: Connection refused 或 SocketException: An existing connection was forcibly closed，大概率是 DNS 变更或服务端 LB 踢掉了长连接。
实操建议：
- 给
HttpClient配置new SocketsHttpHandler { PooledConnectionLifetime = TimeSpan.FromMinutes(2) }，强制短连接轮换 - 禁用 DNS 缓存：
DnsRefreshTimeout = TimeSpan.FromSeconds(30) - 每片请求加唯一
Request-Idheader，方便服务端日志对齐；失败后用指数退避重试（最多 3 次），别用固定间隔 - 不要全局单例一个
HttpClient用于所有上传任务——不同业务域名建议分实例，避免连接池互相干扰
服务端没实现断点续传时，客户端怎么避免重复上传
服务端只支持“全量覆盖”或“追加写入”，但没提供 GET /upload/{id}/status 接口查已传片数，客户端一旦中断就只能重头来——这是最常被忽略的协同漏洞。
实操建议：
- 上传前先发个轻量
HEAD请求到/upload/{fileId}，约定服务端返回X-Uploaded-Chunks: 3表示已存 3 片 - 客户端本地维护一个临时
.uploadstate文件（路径如Path.Combine(Path.GetTempPath(), $"{fileId}.uploadstate")），记录已成功上传的片索引和 MD5 - 重启上传时，跳过本地 state 里标记成功的片，且对每片发请求前校验服务端是否已存在（用
Content-MD5或服务端返回的Etag） - 别依赖文件名做唯一标识——重名文件、用户改名都会崩，必须用文件内容哈希（如
SHA256前 16 字节）生成fileId
进度回调不准、UI 卡死的典型写法坑
用 Progress 订阅 IProgress，却发现进度条跳变、卡顿甚至主线程崩溃——问题往往出在流读取和 UI 更新耦合太紧。
实操建议：
- 别在
FileStream.ReadAsync()回调里直接更新 UI 控件，改用Dispatcher.InvokeAsync()（WPF）或BeginInvoke()（WinForms）异步调度 - 进度粒度别设成“每读 1KB 就回调一次”，改成“每完成一片才触发一次
Report()”，否则高频调用拖垮主线程 - 如果用
BackgroundWorker，注意它的ReportProgress不保证线程安全，仍需检查IsBusy和加锁 - 真正要监控的是“发送完成”而非“读取完成”——
await httpContent.CopyToAsync(...)后再报进度，否则网卡缓冲区还没发出去就显示 100%
分片上传真正的复杂点不在切文件，而在每一片都得过一遍“建连接→发数据→等响应→校验结果→记状态”这个闭环。少一个环节，重试逻辑就可能把同一片发两遍，或者漏掉某片不自知。服务端接口契约比客户端代码更关键——它不支持断点，客户端再努力也只是打补丁。
