mmap + memchr 手动扫描换行符可避免 I/O 流的缓冲开销与字符串扩容：映射文件后用 memchr 批量找 '\n'，以 string_view 切分，零拷贝、无堆分配。
为什么 fgets 或 std::getline 在 GB 级文件上会变慢？
因为它们默认按字符逐个读取并检查 '\n'，每次系统调用都带缓冲区管理开销；更关键的是，当行很长（比如日志中嵌套 JSON）或换行符稀疏时，std::getline 可能反复扩容内部字符串缓冲区，触发多次堆分配。
- 每次
std::getline调用至少一次read()系统调用（取决于 libc 缓冲策略） - 长行场景下，
std::string的指数扩容（如 1→2→4→8…字节）会产生大量临时内存拷贝 -
fgets虽然避免了动态扩容，但需预估最大行长，超长则截断——这对日志、CSV、TSV 等格式不可接受
用 mmap + 手动换行扫描替代 I/O 流，核心怎么做？
把整个文件映射进虚拟内存，用指针遍历找 '\n'，每找到一个就切出一行视图（std::string_view），全程不拷贝内容、不分配堆内存。
- 先用
open()+mmap()映射只读内存（PROT_READ），大小取stat.st_size - 从映射起始地址开始，用
memchr()批量找'\n'（比单字节循环快得多） - 每次找到后，构造
std::string_view{start, found - start}，然后更新start = found + 1 - 注意处理文件末尾无换行符的情况：最后一行需单独判断
start
char* data = static_cast<char*>(mmap(nullptr, size, PROT_READ, MAP_PRIVATE, fd, 0));
char* p = data;
char* end = data + size;
while (p < end) {
char* nl = static_cast<char*>(memchr(p, '\n', end - p));
if (!nl) break;
std::string_view line(p, nl - p);
process(line); // 不拷贝，不分配
p = nl + 1;
}
if (p < end) process(std::string_view(p, end - p)); // 末尾无 \n 的行
mmap 在超大文件上有哪些坑？
不是所有平台都支持任意大小映射，也不是所有场景都适合——尤其当物理内存紧张时，内核可能延迟加载页（page fault），首次访问某段数据反而变慢。
- Linux 上单次
mmap支持 TB 级，但 Windows 的CreateFileMapping对 >4GB 文件需用SEC_LARGE_PAGES或分段映射 - 若文件被其他进程截断，
mmap区域末尾可能读到SIGBUS（需sigaction捕获或提前fstat校验） - 内存映射不等于“立刻加载”：只有实际访问的页才触发磁盘读，所以顺序扫描没问题，但随机跳转可能抖动
- 不要对
mmap区域调用strlen或基于'\0'的函数——文本文件没有结尾零
什么时候该放弃 mmap，退回带缓冲的流式读取？
当你的“超大文件”其实是很多小行（平均 mmap 的优势会被映射/解映射开销抵消；或者你根本不需要随机访问能力，只要顺序吞吐。
立即学习“C++免费学习笔记（深入）”；
- 行平均长度 std::getline 配合
std::ios::sync_with_stdio(false)+cin.tie(nullptr)，性能差距往往不到 20% - 如果要边读边过滤（比如只取含
"ERROR"的行），mmap+memchr仍占优；但若还要做正则匹配或 UTF-8 解码，内存映射带来的控制权提升就更重要 - 容器环境（如 Docker）中，
mmap可能受vm.max_map_count限制，报Cannot allocate memory错误，此时必须降级
真正难的不是选 mmap 还是 read，而是判断哪一行边界算“一行”：Windows 的 "\r\n"、老 Mac 的 "\r"、混用场景下的容错处理——这部分没法靠映射绕过，得自己扫。
