mmap写大文件比fwrite更快是因为将文件直接映射进虚拟内存，写操作变为内存访问，绕过内核缓冲区拷贝和系统调用开销；但更容易出错，因其依赖缺页处理、需显式msync落盘、易触发SIGBUS，且MAP_SHARED、ftruncate预扩展、页面对齐等环节任一失误均导致崩溃或数据丢失。
为什么 mmap 写大文件比 fwrite 更快但更容易出错
因为 mmap 把文件直接映射进虚拟内存，写操作变成内存写，绕过了内核缓冲区拷贝和系统调用开销；但这也意味着你写的每个字节都可能触发缺页异常、写时复制或磁盘 I/O 延迟，一旦进程崩溃或未同步，数据就丢了。普通 fwrite 虽慢，但至少有 libc 缓冲和 fflush 可控点。
关键不是“能不能用”，而是“怎么控制脏页刷盘时机”和“怎么避免 SIGBUS”。常见错误包括：映射只读区域却尝试写、映射长度超过文件当前大小、没调 msync 就退出、用 MAP_PRIVATE 以为能落盘（其实不能）。
-
MAP_SHARED是必须的——只有它才允许修改真正写回文件 - 映射前必须用
ftruncate把文件扩展到目标大小，否则写越界会触发SIGBUS - 写完别依赖 OS 自动刷盘，显式调
msync(addr, length, MS_SYNC)确保落盘 - 如果写入量极大（比如 >10GB），建议分块映射（如每次 128MB），避免
mmap失败或虚拟内存碎片
如何安全地用 mmap + MAP_SHARED 写入超大文件
核心流程是：open → ftruncate → mmap → memcpy/write → msync → munmap。中间任何一步失败都要清理前序资源。
特别注意 ftruncate 必须在 mmap 之前完成，且传入的目标长度要 ≥ 你打算写的最大偏移。Linux 下如果文件系统不支持稀疏文件（比如某些 NFS 或 FAT32 挂载），ftruncate 会实际分配磁盘空间，此时要确保磁盘足够。
立即学习“C++免费学习笔记（深入）”；
- 打开文件用
O_RDWR | O_CREAT，权限设为0644，避免只读打开后mmap失败 -
mmap的length参数必须 ≤ 当前文件大小（由ftruncate设定），否则行为未定义 - 写入时建议按页面对齐（
getpagesize()），非对齐写不会报错，但msync可能刷多余页，影响性能 - 若需追加写而非覆盖，先
lseek+write扩展末尾，再ftruncate，不能只靠mmap自动增长
msync 失败常见原因和应对方式
msync 返回 -1 并设 errno 是最常被忽略的环节。典型错误是 EINVAL（地址或长度非法）、ENOMEM（内核无法分配回写缓冲）、EIO（底层设备写失败）。它不像 write 那样可以部分成功——要么全刷，要么失败。
- 检查
addr是否为mmap返回值，且length是否 ≤ 映射长度 - 避免在多线程中对同一映射区域并发
msync，POSIX 不保证线程安全 - 如果
MS_SYNC太慢，可改用MS_ASYNC+ 定期轮询，但得自己管理“哪些页已提交”状态 - 极端情况下（如磁盘满），
msync失败后应立即munmap并记录错误，不要继续写，否则后续mmap可能失败
Windows 上等效方案是 CreateFileMapping + MapViewOfFile，但行为差异很大
Windows 没有直接对应 mmap 的语义。要用 CreateFileMapping 创建映射对象，再用 MapViewOfFile 获取指针。关键区别在于：映射大小必须 ≤ 文件当前大小，且首次写入前必须用 SetEndOfFile 扩展文件——顺序不能错，否则 MapViewOfFile 成功但写入触发访问冲突。
另外 Windows 的 FlushViewOfFile 对应 msync，但它只保证数据进系统缓存，不保证落盘，真要持久化还得跟 FlushFileBuffers 配合。
- 创建文件时必须用
GENERIC_READ | GENERIC_WRITE，且CreateFileMapping的flProtect设为PAGE_READWRITE -
MapViewOfFile返回NULL时查GetLastError()，常见是ERROR_NOT_ENOUGH_MEMORY（虚拟地址空间耗尽） - 64 位程序下，单次映射建议不超过 2GB，避免在某些旧版 Windows 上触发
STATUS_INVALID_PARAMETER
真正难的不是映射本身，而是把“写内存”和“数据持久化”这两个动作解耦清楚：mmap 让你忘了 I/O，但故障时它也让你更难定位哪段数据到底落盘了没有。
