增量上传是指客户端只上传服务端缺失的文件块，跳过已存在的部分；普通HTTP POST或curl -F每次发送完整文件，造成网络与存储浪费，且不支持断点续传、大文件分片等场景，因其缺乏块级校验机制与客户端分片能力。
什么是增量上传，为什么不能直接用普通 upload
增量上传不是“传一部分再传一部分”，而是指客户端只上传服务端缺失的文件块，跳过已存在的部分。普通 HTTP POST 或 curl -F 每次都发完整文件，网络和存储浪费严重，尤其在断点续传、大文件分片、CDN回源等场景下不适用。
核心前提是服务端必须支持块级校验（比如通过 ETag、Content-MD5 或自定义哈希索引），且客户端能按固定大小切块、逐块查询+上传。
- 服务端没实现块校验逻辑？那所谓“增量”只是客户端单方面假设，极易出错
- 文件被并发修改？块哈希失效，必须加版本号或最后修改时间戳协同验证
- 块大小选 4MB 还是 8MB？影响内存占用和 HTTP 连接复用率，C++ 中建议用
mmap+std::span避免额外拷贝
C++ 客户端如何切块并计算 SHA256
别用 std::ifstream 一行行读——那是文本处理逻辑。二进制块必须按字节精确截取，且哈希计算不能依赖临时 buffer 拷贝。
推荐做法：用 mmap 映射文件（Linux/macOS）或 CreateFileMapping（Windows），配合 openssl/sha.h 流式计算：
立即学习“C++免费学习笔记（深入）”；
unsigned char hash[SHA256_DIGEST_LENGTH]; SHA256_CTX ctx; SHA256_Init(&ctx); SHA256_Update(&ctx, mapped_ptr + offset, chunk_size); SHA256_Final(hash, &ctx); // 转成 hex string: "a1b2c3..."
- 每次
SHA256_Update前检查offset + chunk_size ，避免越界读 - Windows 下若文件大于 4GB，需用
GetFileSizeEx而非GetFileSize - 别把整块读进
std::vector<uint8_t>再哈希——小文件还行，10GB 文件会 OOM
如何和服务端交互判断哪些块要传
典型流程是先发一个 HEAD 或专用 POST /api/v1/chunk/check 请求，带所有块哈希列表，服务端返回缺失块索引数组。
关键点不在 HTTP 库选型（libcurl 或 boost.beast 都可），而在请求体格式和错误处理：
- 用 JSON 数组传哈希：
{"chunks": ["a1b2..", "c3d4.."]}，别拼 query string——长度受限且编码麻烦 - 服务端返回
400 Bad Request时，检查是否因某哈希长度不对（SHA256 必须是 64 字符 hex） - 网络中断后重试，必须重查——不能缓存上次响应，因为服务端块可能已被清理
- 并发查 100 个块？别起 100 个
curl_easy_perform，用curl_multi复用连接池
上传单个块时怎么避免重复和覆盖
上传块本身仍是标准 HTTP 请求，但必须带幂等性控制。常见错误是只靠 URL 区分块，结果多个客户端同时传同一块导致数据错乱。
正确做法：
- 请求头加
Idempotency-Key: <uuid>，服务端据此去重（C++ 生成可用std::random_device+std::uuid库） - 块上传 URL 必须含唯一标识，例如
/upload/{file_id}/chunk/{index}，而非/chunk这种泛接口 - 收到
201 Created才算成功；200 OK可能是服务端返回缓存命中，此时仍需校验响应体中的stored字段是否为true - 上传失败后重试前，先 sleep 指数退避（
100ms * 2^retry_count），避免打爆服务端限流
真正难的不是代码写几行，而是服务端状态一致性——比如块上传成功但元数据未更新，客户端就永远卡在“等确认”。这种边界情况没法靠客户端单方面解决，得和后端对齐事务语义。
