mmap本身只提供字节级随机访问，不支持行号语义，因此必须预建行偏移索引以实现o(1)行定位；否则逐行扫描将退化为o(n)，丧失mmap优势。
直接用 mmap 做大数据检索，不是“只要映射就快”，而是必须配合预建索引、按需分段、零拷贝切片这三件事，否则性能可能比 fread 还差。
为什么 mmap 后还要自己建行偏移索引？
因为 mmap 只提供字节级随机访问能力，不提供“第 N 行在哪”的语义。逐行扫描找 '\n' 会退化成 O(n)，完全浪费 mmap 的 O(1) 地址计算优势。
- 预处理时用
memchr批量扫换行符，比strchr快 3–5 倍；别用std::string::find，它隐式依赖\0 - 索引数组必须用
std::vector<size_t></size_t>，int在超 2GB 文件里会溢出 - 内存敏感场景可降采样：每 1000 行存一个锚点，查第 n 行时先二分找锚点，再从锚点起用
memchr向后找最近的'\n' - Windows 下注意换行是
"\r\n"，但memchr只认'\n'—— 预处理前统一替换或按实际格式解析
如何避免 SIGBUS 和段错误？
最常见的崩溃不是代码写错，而是映射状态和文件实际状态脱节：文件被截断、映射长度没对齐页边界、首次访问触发缺页却没捕获信号。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 映射大小必须用
fstat(fd, &sb)拿sb.st_size，绝不能用lseek(fd, 0, SEEK_END)+ftell，某些伪文件系统（如/proc）不支持 - 长度要向上对齐到页大小：
size_t len = (sb.st_size + getpagesize() - 1) & ~(getpagesize() - 1) - 映射后立即触碰首尾地址（如
((char*)addr)[0]和((char*)addr)[sb.st_size - 1]），强制触发缺页并暴露问题 - 必须检查
mmap返回值是否为MAP_FAILED，否则后续解引用直接 crash
检索结果怎么安全转成 string_view？
std::string_view 是零拷贝的关键，但也是最易误用的点：它的生命周期完全依赖 mmap 区域存活，一旦 munmap，所有 view 全变野指针。
- 函数内返回
std::string_view没问题，但调用方必须保证mmap区域未释放 - 不能用
auto推导后存进容器（如std::vector或 map），那只是存了悬垂指针 - 需要跨函数传递或长期持有？必须显式拷贝：
std::string{sv}，别图省事 - Clang 12 之前对
string_view::data()指针运算有额外运行时检查，关键路径里建议用裸char*偏移
多线程并发搜索要注意什么？
多个线程读同一块 mmap 区域本身是安全的，但“怎么分任务”决定是否真并发、结果是否可靠。
- 绝对禁止重叠区间：线程 A 查
[0, 100MB)，线程 B 查[99MB, 200MB)，跨边界匹配（如 pattern 横跨 99.5MB）会漏掉或重复 - 区间划分必须按页对齐（通常 4KB），否则
mmap调用失败；推荐按固定大小分块（如每块 128MB），末尾不足也单独成块 - 共享结果建议用无锁队列（如
boost::lockfree::queue），频繁匹配时比std::mutex开销低得多 - 不要对整个几十 GB 文件一次性
mmap—— 64 位下也建议单次 ≤ 128MB，避免ENOMEM或缺页风暴卡顿
真正难的不是映射成功，而是让每次 memmem 或行索引查找都落在已加载的物理页上；预热、对齐、分段、生命周期管理，漏掉任一环，mmap 就只是个更脆的指针。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
