C++大文件分片上传需手动控制偏移量、避免内存爆炸、确保字节顺序一致：以binary模式打开文件，用seekg精确跳转并clear()清除failbit，显式传递offset/size至服务端，合并时seekp定位写入并flush，MD5须流式校验完整文件。
大文件分片上传在 C++ 中无法靠单次 fread 或 std::ifstream::read 一气呵成，核心在于手动控制偏移量、避免内存爆炸、确保合并后字节顺序与原文件完全一致——否则视频打不开、PDF 解析失败、校验和对不上。
用 std::ifstream 配合 seekg 精确读取指定分片
不能直接打开文件后连续读，必须对每个分片显式跳转到起始位置。关键点是：文件需以 std::ios::binary 模式打开；seekg 的偏移量单位是字节，且必须是 std::streamoff 类型；每次读前都要检查 failbit，因为跳转可能越界（最后一片常小于片长）。
常见错误现象：seekg 后 read 返回 0 字节，但没报错——其实是流状态被置为 fail，后续操作静默失败。
- 分片起始偏移量 =
chunk_index * chunk_size，注意用static_cast<:streamoff></:streamoff>转换 - 实际读取长度 =
std::min(chunk_size, file_size - offset)，必须手动计算，不能依赖gcount()做唯一判断 - 每次
seekg后立即调用clear()清除可能残留的failbit（尤其上一片读到 EOF 后）
分片上传时如何携带并校验偏移量信息
服务端必须知道每个分片的原始位置，否则合并时顺序错乱。C++ 客户端不能只传二进制数据，必须在 HTTP 请求头或 JSON body 中显式传递 offset 和 size 字段。
立即学习“C++免费学习笔记（深入）”；
使用场景：断点续传。客户端需先向服务端查询已上传的分片列表（例如 GET /upload/status?file_id=abc），再跳过已存在的 offset 区间。
- 推荐在请求头中加
X-Upload-Offset: 1048576和X-Upload-Size: 524288，比放 body 更轻量、更易被 Nginx / CDN 透传 - 服务端返回 200 表示接受该片，返回 204 表示该
offset已存在（跳过）；不要用 409，语义不准确 - C++ 发送时用
curl_easy_setopt(handle, CURLOPT_HTTPHEADER, headers)设置头，别忘了curl_slist_append构造链表
本地合并分片文件必须用 std::ofstream 以 std::ios::binary | std::ios::out 模式逐片追加
不是“把所有分片读进内存再写一次”，而是打开目标文件一次，用 seekp 定位 + write 写入。否则 2GB 文件拆成 100 片，合并时临时占用 2GB 内存+磁盘缓存，极易 OOM。
性能影响：频繁 seekp 在机械硬盘上会有寻道开销，但远小于全量加载；SSD 上可忽略。
- 目标文件需提前
resize到最终大小（ftruncate或 Windows 的SetFilePointerEx+SetEndOfFile），避免合并时文件不断扩展导致碎片 - 每片写入前调用
seekp(offset)，然后write(buf, actual_size)；不要用app模式——它强制追加到末尾，破坏偏移逻辑 - 写完立刻
flush()，防止程序崩溃时部分数据滞留在缓冲区
MD5 校验必须在合并后、且用流式计算而非全文件 load
很多人在分片上传时对每片单独算 MD5，再拼接——这毫无意义。完整文件的 MD5 ≠ 各分片 MD5 拼接，也不等于各分片 MD5 的异或或哈希组合。
容易踩的坑：用 std::filesystem::file_size 获取大小后直接 new char[size] 加载整个文件算 MD5，2GB 文件直接触发 bad_alloc。
- 合并完成后，用
std::ifstream以binary模式打开目标文件，分 8KB~64KB 块循环read+ 更新 MD5 上下文（如 OpenSSL 的EVP_DigestUpdate） - 务必检查每次
read的gcount()，EOF 时停止，不要假设最后一次一定读满 - 如果服务端也做了合并，建议客户端和服务端各自独立计算最终文件 MD5 并比对，这是唯一可靠的完整性验证方式
偏移量不是数字游戏，是字节级的契约。少一个 clear()，多一次 seekg 失败未检测，合并后的文件就差一个字节——而这个字节往往在文件头，导致整个文件不可用。
