断点续传需以二进制模式打开文件，用seekg()/seekp()定位偏移量，配合原子写入offset文件、分块读写校验gcount()、并发加锁保护，确保偏移量持久化可靠。
用 seekg() 和 seekp() 定位到断点位置
断点续传本质是让文件读写从上次中断的字节偏移处继续，C++ 的 std::ifstream 和 std::ofstream 都支持基于字节的随机定位。关键不是“怎么打开”，而是“打开后怎么跳到指定位置”。seekg() 控制读取位置（get），seekp() 控制写入位置（put），二者都接受 std::ios_base::beg、std::ios_base::cur、std::ios_base::end 三种基准模式。
常见错误是：打开文件时没加 std::ios::binary，导致文本模式下换行符被转换，seekg(100) 实际跳不到第 100 字节；或者用 seekg(pos, std::ios::end) 想倒着找位置，却忘了 pos 是负数（如 seekg(-10, std::ios::end) 才是末尾前 10 字节）。
- 必须以
std::ios::binary模式打开文件，否则偏移量不可靠 - 写入前调用
seekp(offset)，读取前调用seekg(offset)，offset是std::streamoff类型（通常是long long） - 定位后建议检查是否成功：
if (!ifs.seekg(offset)) { /* 失败 */ } - 定位到末尾获取当前大小：
ofs.seekp(0, std::ios::end); auto size = ofs.tellp();
如何安全记录和读取断点偏移量
断点信息不能硬编码，也不能存在内存里——程序崩溃就丢了。最简单可靠的方式是把已传输字节数写进一个独立的元数据文件（如 file.part.offset），每次启动先读它，传输中定期刷新。
注意：写偏移量本身也要防损坏。不要直接覆盖原 offset 文件，而是写到临时文件再原子重命名（Windows 用 MoveFileEx，Linux/macOS 用 rename()）。C++ 标准库不提供原子重命名，需调用系统 API 或用 std::filesystem::rename()（C++17 起）。
立即学习“C++免费学习笔记（深入）”；
- 保存偏移量用
std::ofstream文本写入更稳妥（避免二进制字节序歧义）：std::ofstream ofs("file.part.offset"); ofs << static_cast(bytes_transferred); - 读取时用
std::ifstream+>>提取，失败则默认从 0 开始 - 不要用
std::ofstream直接写二进制偏移量——跨平台时sizeof(std::streamoff)可能不同 - 频繁刷盘影响性能，可设阈值（如每 64KB 或每 5 秒）才更新 offset 文件
分块读写时如何处理最后一块不足缓冲区大小
断点续传必然面临“剩余多少字节要传”的问题。假设总大小为 1025 字节，已传 1000 字节，只剩 25 字节，但你的缓冲区是 1024 字节——这时不能无脑 read(buf, 1024)，否则会读到 EOF 后的垃圾或触发 failbit。
正确做法是：计算剩余待传字节数 remaining = total_size - offset，然后用 read(buf, std::min(remaining, buf_size))。同时必须检查 gcount() 返回实际读取字节数，它可能小于请求值（比如磁盘突然拔出、权限变化）。
-
ifs.read(buf, n)不保证读满n字节，必须用ifs.gcount()获取真实读取量 - 写入端同理：
ofs.write(buf, actual_read)，不能直接写n - 如果
gcount() == 0且!ifs.eof()，说明出错（如 I/O 错误），应中止并记录错误码 - 传输完成前，务必调用
ofs.flush()确保数据落盘，再更新 offset 文件
多线程环境下断点文件竞争问题
如果多个线程/进程同时操作同一个文件（比如一个在下载，一个在监控进度），offset 文件极易被覆盖。标准文件流本身不是线程安全的，seekp() + write() 不是原子操作。
最轻量的解决方式是加文件锁：flock()（Unix-like）或 LockFile()（Windows）。不要依赖 C++ 标准库的 sync_with_stdio(false)——它只影响 C 和 C++ 流的同步，不解决并发写 offset 的问题。
- 写 offset 前获取独占锁，写完立即释放；读 offset 时也应加共享锁（防止读到半截内容）
- 避免用
std::fstream长时间持有文件句柄——锁粒度越小越好 - 更健壮的做法是改用数据库（如 SQLite）存 offset，利用事务保证一致性
- 调试时可用
lsof -p PID（Linux/macOS）或 Process Explorer（Windows）确认文件锁状态
断点续传真正难的不是定位，而是偏移量的持久化时机和并发保护——哪怕 seekp() 调用成功，如果 offset 文件没及时、安全地更新，下次启动还是从头开始。
