windows 用 createfilemapping+mapviewoffile，linux 用 mmap；二者句柄类型、错误码（null vs map_failed）、偏移对齐（64kb vs 4kb）、同步机制（flushviewoffile+flushfilebuffers vs msync）及资源释放（双句柄关闭 vs 单 munmap）均不兼容，必须分平台实现。
Windows 和 Linux 下 mmap 等价接口差异在哪
直接套用 mmap 在 Windows 上会编译失败，因为 Windows 没有 POSIX mmap；而 Linux 用 CreateFileMapping 又太重、API 风格不一致。跨平台封装第一关就是对齐语义：映射创建、视图映射、同步、关闭。
核心差异点：
- Linux 用 open + mmap + msync + munmap
- Windows 用 CreateFile + CreateFileMapping + MapViewOfFile + FlushViewOfFile + UnmapViewOfFile + CloseHandle（文件句柄和映射句柄要分别关）
- 映射粒度不同：Linux 默认按页对齐（4KB），Windows 要求 MapViewOfFile 的偏移必须是 64KB 倍数（否则失败），但起始地址可任意对齐
- 不要试图让 Windows 的
MapViewOfFile偏移为任意值——它会静默失败或返回NULL，需手动向下对齐到 64KB 边界 - Linux 的
mmapoffset必须是页大小倍数（getpagesize()），否则EINVAL - 两者都要求文件大小 ≥ 映射长度，且 Windows 要求提前用
SetFilePointer+SetEndOfFile扩展文件（Linux 可用ftruncate）
如何设计一个不依赖 Boost 或 std::filesystem 的轻量级类接口
目标是头文件仅依赖 <cstdint></cstdint>、<memory></memory>、<string></string> 和系统头（sys/mman.h / windows.h），避免引入构建复杂性。关键不是“多抽象一层”，而是把平台差异收进实现，暴露统一语义。
推荐接口签名：
class MemMappedFile {
public:
explicit MemMappedFile(const std::string& path);
~MemMappedFile();
<pre class="brush:php;toolbar:false;">bool open(uint64_t offset, size_t length, bool writable = false);
void* data() const { return ptr_; }
size_t size() const { return length_; }private: std::string path; void* ptr = nullptr; sizet length = 0;
ifdef _WIN32
HANDLE hFile_ = INVALID_HANDLE_VALUE; HANDLE hMap_ = nullptr;
else
int fd_ = -1;
endif
};
-
open()应返回bool，失败时自动清理已有资源（比如 Windows 上已打开的hFile_） - 构造函数只存路径，不立即打开——用户可能只读元数据或延迟初始化
- 不要在析构里抛异常（C++ 标准禁止），出错只记录日志或 assert
- Linux 下
mmap失败返回MAP_FAILED（即(void*)-1），Windows 下MapViewOfFile失败返回NULL，判空逻辑要分开写
写入同步和持久化容易被忽略的坑
内存映射本身不保证数据落盘。用户常误以为 memcpy 到 data() 就完事了，其实只是改了页缓存——断电或 crash 时可能丢失。
- Linux：必须调
msync(ptr_, length, MS_SYNC)（MS_ASYNC不保证落盘）；munmap不触发写回 - Windows：必须调
FlushViewOfFile(ptr_, length)；UnmapViewOfFile不刷盘 - 若映射时用了
MAP_SHARED（Linux）或FILE_MAP_WRITE（Windows），且底层文件是普通磁盘文件，刷盘后才真正持久化 - 注意：SSD/F2FS 等文件系统可能有 write-back cache，即使
msync成功，仍需fsync(fd_)或FlushFileBuffers(hFile_)才能确保设备级持久
小文件 vs 大文件映射的性能取舍
映射不是万能加速器。对小于 4KB 的文件，开销（系统调用、页表项、TLB 压力）可能远超直接 read()；对 GB 级文件，又得考虑虚拟内存碎片和 OOM 风险。
- 建议阈值设为 ≥ 64KB 再启用 mmap；小文件走传统 I/O 更稳
- Windows 下一次
MapViewOfFile最大支持约 2GB（32 位进程）或受限于可用虚拟地址空间（64 位），不要尝试单次映射整个 TB 文件 - Linux 下可多次
mmap同一文件不同 offset，但每个映射都是独立 VMA，频繁映射/解映射比维护一个大映射更耗 CPU - 如果只读且随机访问，mmap 有优势；如果顺序扫描+写入，
read/write+ 缓冲区可能更可控
跨平台封装最难的部分不是写通两个平台，而是让使用者不用查文档就知道：什么时候该 flush，为什么 Windows 映射失败却没报错，以及为什么 mmap 后文件大小没变——这些细节藏在系统行为里，没法靠接口名掩盖。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
