应分块映射超大文件：Windows用MapViewOfFile按4–64MB分段映射并确保偏移对齐dwAllocationGranularity，Linux用mmap配合madvise(MADV_WILLNEED)替代MAP_POPULATE，并严格校验访问边界。
Windows 下用 CreateFileMapping 读超大文件，别直接映射整个文件
映射几十 GB 文件时，CreateFileMapping 调用成功不代表内存就到位了——它只创建映射对象，真正触发页错误（page fault）时才从磁盘拉数据。但若你 MapViewOfFile 映射了全部视图，系统可能立刻尝试提交大量物理页，导致 ERROR_COMMITMENT_LIMIT 或卡死。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 按需映射：用
MapViewOfFile的dwNumberOfBytesToMap参数控制每次只映射几 MB（比如 4–64 MB），避开单次大映射 - 映射前调用
SetFileValidData（需管理员权限）可跳过零初始化，提速；但仅适用于你确定后续会写满该区域的场景 - 注意
SEC_COMMIT和SEC_RESERVE标志区别：前者立即分配页面，后者只预留地址空间——读文件用SEC_COMMIT即可，别混用
Linux 下 mmap 映射超大文件，MAP_POPULATE 不是万能加速键
加 MAP_POPULATE 确实会让 mmap 返回前预读页面，但对上百 GB 文件，它会阻塞很久，且可能因内存不足被 OOM killer 干掉——尤其在没有 swap 或 vm.swappiness=0 的机器上。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 去掉
MAP_POPULATE，改用madvise(fd, MADV_WILLNEED)提前提示内核预读，更轻量、可控 - 读取时用
mincore()检查某段是否已入内存，避免盲等；但注意它不保证原子性，返回1只表示“当前在内存”，下一秒可能就被换出 -
mmap后别直接memset整块——这会强制所有页提交，等同于自造MAP_POPULATE
跨平台代码里，MapViewOfFile 和 mmap 的偏移对齐要求不一样
Windows 要求 MapViewOfFile 的 dwFileOffsetLow/dwFileOffsetHigh 必须是系统分配粒度（GetSystemInfo().dwAllocationGranularity，通常是 64 KB）的整数倍；Linux 的 mmap 则要求 offset 是 getpagesize()（通常 4 KB）的倍数。两者不兼容，硬写死 4 KB 对齐在 Windows 上会失败。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- Windows 下用
GetSystemInfo获取dwAllocationGranularity，并把文件偏移向上对齐到该值 - Linux 下用
sysconf(_SC_PAGESIZE)获取页大小，偏移对其对齐 - 不要用
#define ALIGN 4096统一处理——这是最常踩的跨平台坑
映射后访问越界不会立刻报错，但 ACCESS_VIOLATION 或 Segmentation fault 很难定位
内存映射区域外的读写，不会像普通数组越界那样触发编译器检查或 std::out_of_range，而是由 MMU 在硬件层抛异常。Windows 上表现为未捕获的 EXCEPTION_ACCESS_VIOLATION，Linux 上是 SIGSEGV，堆栈里往往只剩汇编帧，看不出哪行 C++ 代码越界。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每次
MapViewOfFile/mmap后，用变量明确记录映射长度（不是文件长度），所有指针运算必须基于该长度做边界检查 - 调试时 Windows 可用
VirtualQuery查某地址是否在映射区内；Linux 用/proc/self/maps手动比对 - 禁用
-O2以上优化再调试——编译器可能把边界检查优化掉，让问题更隐蔽
真正麻烦的不是映射本身，而是你忘了映射区是虚拟地址空间的一部分：它不自动随文件增长而扩展，也不帮你做并发读保护，更不会在 std::vector 里安静待着。
