核心是用std::filesystem::exists()和file_size()判断文件存在性及长度，而非时间戳或标记文件；续传需随机写入（ios::in|out|binary+seekp），并用元数据文件记录可靠写入位置，最终通过原子rename提交。
如何判断文件是否已存在且需要续传
核心是用 std::filesystem::exists() 和 std::filesystem::file_size() 获取已有文件长度，而非依赖时间戳或自定义标记文件。时间戳不可靠（如服务重启、时钟回拨），标记文件又多一次 I/O 开销。
注意：调用 file_size() 前必须确保文件存在且可读，否则抛出 std::filesystem::filesystem_error。建议用 try/catch 包裹，或先用 exists() 检查。
- 若文件不存在 → 从 offset 0 开始写
- 若文件存在且大小 > 0 → 将写入起始 offset 设为
file_size()返回值 - 若文件存在但大小为 0 → 视业务而定：可清空重写，也可按续传处理（需额外协议约定）
用 std::ofstream 追加写入时的坑
std::ofstream 的 std::ios::app 模式看似适合续传，但它强制将所有写入定位到文件末尾，无法控制偏移量 —— 这意味着你不能跳过中间损坏段、也不能覆盖重传某一段。真正的断点续传需要随机写入能力。
正确做法是用 std::ofstream 打开时指定 std::ios::in | std::ios::out | std::ios::binary，再用 seekp(offset) 定位：
立即学习“C++免费学习笔记（深入）”；
std::ofstream file(path, std::ios::in | std::ios::out | std::ios::binary);
if (file.is_open()) {
file.seekp(existing_size); // 定位到已有长度处
file.write(buffer, n);
}
- 必须带
std::ios::in，否则seekp()在某些平台（如 Windows MSVC）可能失效 - 必须用
std::ios::binary，避免文本模式下换行符转换干扰实际字节偏移 - 写入后建议调用
file.flush()，尤其在分块写入场景中，防止缓冲区未落盘导致下次探测长度不准
并发写入时如何安全探测长度
多个进程/线程同时写同一文件时，仅靠 file_size() 探测会出错：A 进程刚读到长度 L，B 进程立刻追加了数据，A 接着从 L 写入就会覆盖 B 的新内容。
解决方案不是加锁整个文件（跨进程难实现），而是让写入方自己维护“已确认写入长度”：
- 每次成功写入一块后，原子更新一个独立的元数据文件（如
xxx.part.length），只存一个整数 - 启动时优先读这个元数据文件；若不存在或读取失败，再 fallback 到
file_size() - 元数据文件用
std::ofstream(..., std::ios::trunc)覆盖写入，并调用fsync()（Linux）或FlushFileBuffers()（Windows）确保落盘
这样即使主文件被其他程序意外截断，元数据仍能反映上一次可靠写入位置。
写入完成后如何避免残留临时状态
断点续传逻辑常伴随临时文件或“.part”后缀，但很多人忽略最终原子提交步骤：直接 rename 或替换原文件可能在崩溃时丢失数据。
推荐两阶段提交：
- 写入全程操作
target_file.part - 写入完成且校验通过（如 CRC32 / SHA256）后，调用
std::filesystem::rename("target_file.part", "target_file")
rename() 在同文件系统内是原子操作，不会出现“只有半份文件”的中间态。但注意：rename() 在 Windows 上若目标已存在会失败，需先 remove() 目标再 rename；Linux 则直接覆盖。
真正容易被忽略的是：校验必须在 rename 之前做，且校验范围应包含全部已写入字节（即按元数据长度读，而非 file_size() 当前值）—— 否则可能校验了未 flush 的缓冲区内容。
