根本原因是 ifstream 默认缓冲区仅4KB，导致频繁系统调用和换行搜索开销；pubsetbuf()需在open前调用且跨平台支持差；推荐用binary read+大缓冲+手动解析，吞吐可达100+MB/s。
为什么 ifstream 读大文件会越来越慢？
根本原因不是磁盘 IO 本身变慢，而是默认 std::ifstream 的内部缓冲区太小（通常仅 4KB），导致频繁系统调用 read() 和用户态/内核态切换；更隐蔽的是，若文件含大量换行符且你用 getline() 逐行读，每次都要在小缓冲区内反复搜索 '\n'，实际有效吞吐可能跌到几十 KB/s。
手动设置 rdbuf()->pubsetbuf() 为什么常失效？
这是最易踩的坑：pubsetbuf() 必须在流打开前调用，且只对某些标准库实现（如 libstdc++）生效；MSVC 的 msvcp 完全忽略它。即使生效，也不能保证缓冲区被完全使用——比如你传入 64KB 缓冲区，但 getline() 内部仍可能因边界检查拆成多次小读取。
- 正确时机：
std::ifstream fs; fs.rdbuf()->pubsetbuf(buf, bufsize); fs.open("big.log"); - 缓冲区必须是静态或长期存活的内存（不能是栈上局部数组）
- 推荐改用更可控的底层方式：直接
read()+ 手动解析
用 read() + 自定义缓冲解析替代 getline()（实测提速 5–20 倍）
绕过流缓冲和格式化开销，用大块读取 + 状态机解析，对日志类文本尤其有效。关键不是“快”，而是“可预测”——吞吐量基本稳定在磁盘顺序读极限（如 100+ MB/s）。
char buf[1024 * 1024]; // 1MB buffer
std::ifstream fs("access.log", std::ios::binary);
fs.read(buf, sizeof(buf));
size_t n = fs.gcount();
// 然后用指针遍历 buf，找 '\n' 分割行（注意跨块边界！）
- 务必加
std::ios::binary，避免 Windows 下\r\n被静默转换 - 跨缓冲区的行（即最后一行没结束）需缓存尾部碎片，下次读取前拼接
- 若需跳过 BOM 或处理 UTF-8，解析逻辑要提前判断字节序列，别依赖 locale
mmap 比 ifstream 更快吗？什么时候该切？
Linux/macOS 下 mmap() 在首次访问页时才触发缺页中断，看似“零拷贝”，但真实场景中：若你随机访问大文件中的某几行，mmap 有优势；但纯顺序扫描整文件，read() 配合预读（posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)）往往更稳，且无虚拟内存压力。
立即学习“C++免费学习笔记（深入）”；
- Windows 用
CreateFileMapping+MapViewOfFile，但要注意大文件映射失败率高（地址空间碎片） - 不要 mmap 超过物理内存 2 倍的文件——会导致 swap 颠簸，反而更慢
- 调试时用
/proc/[pid]/maps或vmmap确认是否真映射成功，而非只看 open 是否返回非空
真正卡住的点永远不在“选哪个 API”，而在是否让 CPU 处理和磁盘读取重叠——比如用两个线程：一个专职 read() 填缓冲队列，另一个解析已填满的块。这点连很多 C++17 的 std::filesystem 教程都故意绕开了。
