mmap失败主因是页对齐错误、32位地址空间不足、max_map_count限制或文件类型不支持；memchr/strstr比std::string::find快因无对象构造开销且直接操作裸指针。
内存映射读取大文件时，mmap 失败或返回 MAP_FAILED 怎么办
常见现象是程序在 1GB+ 文件上调用 mmap 后直接失败，错误码常为 ENOMEM 或 EINVAL。这不是代码写错了，而是系统限制或参数不匹配。
-
length必须严格对齐页大小（通常 4KB），传入未对齐值会触发EINVAL；可用sysconf(_SC_PAGESIZE)获取并向上取整 - 32 位进程虚拟地址空间有限（约 3GB 可用），千万行文本文件轻松超 2GB，
mmap必然失败；必须确认编译目标为x86_64 - Linux 默认限制单次
mmap区域大小（/proc/sys/vm/max_map_area），超限会报ENOMEM；临时调高可执行：echo 65536 > /proc/sys/vm/max_map_count - 文件需有读权限，且不能是 FIFO、socket 等不支持 mmap 的类型；用
stat()检查st_mode是否含S_IFREG
用 memchr 和 strstr 在 mmap 区域里找关键词，为什么比 std::string::find 快
因为前者操作的是裸指针，无构造/析构开销，也不拷贝数据；而 std::string 查找默认要先构造临时对象，对千万行文本来说，每行都 new + delete 就是灾难。
-
memchr适合找单字节关键词（如换行符'\n'），底层常由汇编优化，速度接近内存带宽极限 -
strstr是标准 C 函数，对短关键词（ - 不要用
std::search配std::boyer_moore_searcher——构建 pattern 表本身就有 O(m) 开销，在单次检索场景下反而更慢 - 若关键词固定且较短（如 “ERROR”、“WARN”），可手写 SSE4.2 的
_mm_cmpistrm加速，但需运行时检测 CPU 支持，普通项目不推荐
逐行扫描 mmap 区域时，如何避免越界和误判换行符
文件末尾没换行、Windows 的 "\r\n"、二进制数据混入文本——这些都会让基于 '\n' 的切分出错，导致某一行指针指向非法地址或漏掉最后一行。
- 映射区域起始地址为
addr，长度为len，则有效范围是[addr, addr + len)；所有指针运算必须在此区间内，不可假设addr[len-1]存在 - 找行首时，从上一行结束位置开始用
memchr(curr, '\n', remaining_len)，并检查返回值是否为nullptr - 遇到
'\r'后紧跟'\n'，应统一视为一个换行，跳过两个字节；否则"\r\n"被当两行，第二行为空字符串 - 最后一行若无换行符，需在循环结束后单独处理：
if (curr
关键词命中后，怎么快速定位到原始行号而不遍历全部前面的行
行号不是元数据，得靠统计换行符个数。但千万行全扫太慢，得用“预建索引 + 二分”策略，而不是每次现场数。
立即学习“C++免费学习笔记（深入）”；
- 启动时一次性扫描 mmap 区域，用
memchr批量找'\n'，把每个换行符地址存入std::vector<const char></const>；该向量即“行偏移索引”，构建耗时约 200ms（SSD，10GB 文本） - 关键词命中地址为
hit_ptr，用std::lower_bound在索引中查找首个 ≥hit_ptr的地址，其下标就是行号（从 0 或 1 开始按需加一） - 索引内存开销约为每行 8 字节，千万行约 80MB，远小于原文件，且可复用多次检索
- 若内存极度受限，改用稀疏索引：只存每 1000 行的地址，定位时最多回溯 1000 行再线性计数，平衡内存与速度
真正卡住性能的往往不是 mmap 或查找算法，而是忘记 madvise(addr, len, MADV_DONTNEED) 清理冷页，或者在多线程里共享同一块 mmap 区域却没加锁保护指针遍历状态。这些细节不报错，但会让吞吐量掉一半。
