因为Windows与POSIX的内存映射行为存在根本差异：稀疏映射支持、错误处理机制、对齐要求（Windows需64KB对齐）、释放约束及多段映射管理不同，直接封装会导致跨平台静默失败，必须抽象统一的按需映射语义并严格隔离平台细节。
为什么不能直接用 mmap 或 CreateFileMapping 做跨平台封装
因为 Windows 的 CreateFileMapping + MapViewOfFile 和 POSIX 的 mmap 行为差异远不止函数名不同：Windows 默认不支持稀疏映射（FILE_MAP_COPY 会强制分配物理页），而 mmap 的 MAP_PRIVATE 在大文件下可能触发 ENOMEM；更关键的是，POSIX 下 mmap 失败通常返回 MAP_FAILED，Windows 下 MapViewOfFile 失败返回 NULL，但错误码需调用 GetLastError() 获取——混用会导致 TB 级文件在某平台静默失败。
所以必须抽象出统一的“按需映射视图”语义，而非简单包装系统调用。
- 不要一次性映射整个 TB 文件——哪怕 64 位地址空间也扛不住碎片化和 OS 限制
- 必须支持多段独立映射（例如只映射第 2TB 的 128MB），且能安全重叠/释放
- Windows 上要显式调用
FlushViewOfFile+UnmapViewOfFile，POSIX 下msync+munmap是可选但写入一致性必需
如何设计 MemoryMappedFile 基类的核心接口
重点不是“怎么打开文件”，而是“怎么安全访问任意偏移”。接口必须隔离平台细节，暴露最小必要能力：
-
bool map_range(size_t offset, size_t length, bool writable)：仅映射指定区间，成功后返回true，offset必须对齐到系统页大小（getpagesize()/GetSystemInfo().dwAllocationGranularity） -
void* view() const：返回当前映射区基址，未映射时返回nullptr -
size_t mapped_length() const：返回当前映射长度（非文件总长） -
bool flush_range(size_t offset, size_t length)：仅刷指定子区间，避免全量msync阻塞
注意：map_range 必须允许重复调用——比如先映射 [0, 1GB)，再映射 [512GB, 512GB+1GB)，两次映射互不干扰。Windows 下每次调用 MapViewOfFile 都需独立句柄，POSIX 下则需确保 mmap 的 offset 参数与文件偏移对齐。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
TB 级文件下最容易被忽略的对齐与释放陷阱
常见崩溃不是来自映射失败，而是释放时错配：
- Windows：
UnmapViewOfFile的地址必须严格等于MapViewOfFile返回值，哪怕差 1 字节都会触发STATUS_INVALID_PARAMETER（错误码87） - POSIX：
munmap的addr必须是mmap返回的原始地址，且length必须与映射时一致——不能用mapped_length()直接传入，因为实际映射长度可能因页对齐向上取整 - 所有平台都要求
offset和length对齐到页大小（4096或65536），但 Windows 的MapViewOfFile还额外要求offset对齐到64KB（dwAllocationGranularity），否则调用失败且GetLastError()返回ERROR_INVALID_PARAMETER
示例：在 Windows 上想映射文件偏移 0x100000（1MB）开始的 1MB 数据，必须确保 0x100000 % 65536 == 0，否则 MapViewOfFile 直接失败——这个约束在 Linux mmap 里不存在，但跨平台封装必须统一按最严平台（Windows）对齐。
轻量级实现的关键取舍点
不做自动内存管理（比如 RAII 自动 unmap），因为 TB 文件往往需要长期驻留多个视图，生命周期由业务逻辑控制；也不做内部缓存层——那会模糊“映射即访问”的语义，增加一致性风险。
- 每个
map_range调用对应一次系统调用，不合并、不预分配 - 不隐藏
errno/GetLastError()，提供last_error()接口供调试，但默认不抛异常（避免大文件操作中异常开销） - 文件打开句柄（
int fd/HANDLE）由用户传入，不接管open/CreateFile，避免权限、共享模式等歧义
真正难的不是映射本身，而是让多线程在不同偏移上并发 map_range / flush_range 时不踩内存或句柄——这意味着内部必须用 std::mutex 保护映射表（存储 offset→view_ptr 映射），但锁粒度不能粗到阻塞整个文件操作。TB 级场景下，这点比语法糖重要得多。
