C++标准库不提供跨平台内存映射接口，mmap仅用于POSIX系统，Windows需用CreateFileMapping+MapViewOfFile；二者不兼容，仅只读顺序扫描可统一封装。
memory-mapped I/O在C++里用mmap，不是std::ifstream的替代品
直接说结论：C++标准库不提供跨平台的内存映射接口，mmap是POSIX系统（Linux/macOS）原生API，Windows要用CreateFileMapping+MapViewOfFile。想靠std::fstream打开10GB文本并“高效读取”，不映射根本扛不住——频繁seekg和read会触发大量系统调用和缓冲区拷贝，IO吞吐直接掉一个数量级。
用mmap的本质是让内核把文件某段直接映射进进程虚拟地址空间，之后读文件就像读数组一样。但注意：它不自动解析行、不处理编码、不管理换行符边界——你拿到的是原始字节流，得自己找'\n'。
Linux下用mmap读超大文本的最小可靠流程
核心步骤缺一不可，漏掉任意一步都可能崩溃或读错：
-
open()必须带O_RDONLY，且返回fd不能为-1；大文件建议加O_NOATIME避免更新访问时间 -
stat()获取st_size，这是mmap的length参数唯一可信来源；别用lseek(fd, 0, SEEK_END)，对某些文件系统（如procfs）会失败 -
mmap()的prot设PROT_READ，flags必须含MAP_PRIVATE（只读场景不用MAP_SHARED） - 映射成功后，务必检查返回指针是否为
MAP_FAILED；失败时errno可能是ENOMEM（虚拟内存不足）或EINVAL（offset未按页对齐） - 用完必须
munmap()+close()，否则fd泄漏+虚拟内存泄漏
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
int fd = open("/huge.log", O_RDONLY | O_NOATIME);
struct stat sb;
fstat(fd, &sb);
char* data = static_cast<char*>(mmap(nullptr, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0));
if (data == MAP_FAILED) { /* handle error */ }
// ... 使用data作为只读字节数组
munmap(data, sb.st_size);
close(fd);
逐行解析时最容易崩的三个点
内存映射后不能直接拿std::string或std::getline硬套——它们内部会尝试修改缓冲区或越界读取，而映射区域可能末尾没'\n'，也可能被内核回收部分页。
- 必须手动遍历找
'\n'：从当前pos开始扫，直到data[i] == '\n'或i == file_size；别用strchr，它遇到\0就停，而文本里可能有二进制零 - 行末尾要小心：最后一行若无换行符，
substr(pos, end-pos)会截到文件尾，但end必须≤sb.st_size，否则越界访问触发SIGBUS - 避免缓存整行：10GB文件里单行若达500MB（比如base64嵌入），
std::string构造会分配失败；应传std::string_view{data + pos, len}做视图处理
Windows上等效实现的关键差异
Windows没有mmap，但行为可对齐：核心是CreateFileMapping创建对象，再用MapViewOfFile获取指针。区别在于：
-
CreateFile要加GENERIC_READ和FILE_ATTRIBUTE_READONLY，CreateFileMapping的flProtect用PAGE_READONLY -
MapViewOfFile的dwNumberOfBytesToMap不能超过文件大小，且dwFileOffsetHigh/dwFileOffsetLow必须按64KB对齐（比POSIX的4KB更严） - 释放顺序固定：
UnmapViewOfFile→CloseHandle(hMap)→CloseHandle(hFile)；颠倒顺序会导致句柄泄漏 - 跨平台封装建议：用宏区分
#ifdef _WIN32，不要试图用Boost.Iostreams或mman-win32这类第三方——它们抽象层会引入额外拷贝或页对齐bug
真正麻烦的从来不是映射本身，而是后续怎么安全地当“巨型字符数组”用：页边界、空字符、未终止行、多线程并发访问——这些细节不处理，程序可能在99%的数据上跑通，唯独在某个2GB偏移处崩给你看。
