std::ofstream::seekp 多线程下非线程安全，会导致文件指针错乱、数据覆盖；正确做法是预分配文件大小，各线程独占 fd/handle，用 pwrite（Linux）或 WriteFile+OVERLAPPED（Windows）进行偏移写入。
std::ofstream::seekp 在多线程下直接调用会崩
不是线程安全的。多个线程同时对同一个 std::ofstream 对象调用 seekp + write，会导致文件指针错乱、数据覆盖或写入失败——C++ 标准库的流对象几乎都不支持并发访问。
- 即使每个线程写入的 offset 不重叠，
seekp和后续write之间没有原子性，中间可能被其他线程打断 - 底层 file descriptor 的 position 是共享状态，
lseek+write组合在 POSIX 层也不保证原子跨线程 - Windows 上
SetFilePointerEx+WriteFile同样不解决竞争问题，除非用OVERLAPPED或单独句柄
正确做法：每个线程独占一个文件句柄 + 预分配空间
核心是绕过流对象的内部状态竞争，改用底层系统调用或明确控制写入位置。先用 ftruncate（Linux/macOS）或 SetEndOfFile（Windows）把文件拉到最终大小，再让每个线程打开同一文件的**独立 fd/handle**，用 pwrite（Linux/macOS）或 WriteFile 配 OVERLAPPED（Windows）做偏移写入。
- Linux 示例：用
open(path, O_RDWR | O_CREAT)每个线程开一次，然后pwrite(fd, buf, size, offset)—— 这个函数本身是原子的，不依赖当前文件指针 - Windows 示例：用
CreateFile打开时加FILE_FLAG_NO_BUFFERING（可选），WriteFile必须配合初始化好的OVERLAPPED结构体，其中Offset和OffsetHigh显式指定位置 - 预分配不可省：否则
pwrite写越界会失败（返回 -1 并设errno = EINVAL），Windows 同理
合并环节根本不需要“合并”
分段下载 + 定位写入完成后，文件已经是完整内容，不存在“合并文件”的步骤。所谓“合并”，其实是误以为各线程写的是临时文件——那才需要后续拼接。真并发写入同一文件，完成即就绪。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 如果用了临时文件（如
part_0.bin,part_1.bin），那是放弃定位写入优势，又回到单线程顺序拼接的老路，还多出磁盘 IO 和 rename 成本 - 检查是否成功：下载完对整个文件做一次
lseek(fd, 0, SEEK_END)确认长度，再用md5sum或内存 mmap 校验分段 hash - 注意：不要用
std::filesystem::copy_file(..., copy_options::append)来“合并”，它不支持偏移，只会追加
附最小可行源码片段（Linux）
int fd = open("target.bin", O_RDWR | O_CREAT, 0644);
ftruncate(fd, total_size); // 预分配
<p>// 每个线程：
char buf[64 <em> 1024];
ssize_t n = download_chunk(..., buf, sizeof(buf));
ssize_t written = pwrite(fd, buf, n, start_offset); // start_offset 由分段逻辑算好
if (written != n) { /</em> 处理错误，比如磁盘满或中断 */ }</p>Windows 版需封装 OVERLAPPED 初始化和 WriteFile 调用，关键点是每次调用前设置 ol.Offset = static_cast<dword>(offset & 0xFFFFFFFF)</dword> 和 ol.OffsetHigh = static_cast<dword>(offset >> 32)</dword>。
立即学习“C++免费学习笔记（深入）”；
真正麻烦的从来不是怎么写，而是怎么让所有线程对齐 offset、处理断点续传、应对网络超时重试——这些逻辑一旦没压住，seekp 即便线程安全也救不了下载完整性。
