不能直接用std::ifstream::read一次性读完超大文件，因内存不足会导致std::bad_alloc；即使分配成功，缓存失效和页交换也会使性能下降十倍以上。
为什么不能直接用 std::ifstream::read 一次性读完超大文件
因为内存不够。比如一个 20GB 的日志文件，new char[20ULL * 1024 * 1024 * 1024] 直接失败，std::bad_alloc 是最常见结果。更隐蔽的问题是：即使系统允许分配（如使用虚拟内存），后续处理时缓存失效、页交换会拖慢十倍以上——这不是 IO 瓶颈，是内存访问模式问题。
按块读取的核心不是“分多次调用 read”，而是控制每次真正加载进物理内存的数据量，并让 OS 缓存策略与你的访问顺序对齐。
用固定大小缓冲区 + read 循环是最稳的方案
不要依赖 gcount() 判断是否读到末尾——它只反映上一次 read 实际读入字节数，而 EOF 可能在任意位置发生。正确做法是检查 rdstate() 并结合 gcount()。
-
std::ifstream必须用std::ios::binary模式打开，否则 Windows 下遇到\r\n会被静默转换，块边界错乱 - 缓冲区大小建议设为 4KB–64KB（如
constexpr size_t BUF_SIZE = 8192;），太小导致 syscall 过多，太大无益于性能提升 - 每次
read(buf, BUF_SIZE)后立刻检查：if (file.gcount() == 0 && file.eof()) break;，避免空循环 - 处理最后一块时，
gcount()返回值就是真实可用字节数，不要硬当成满缓冲区用
constexpr size_t BUF_SIZE = 32768;
std::ifstream file("huge.log", std::ios::binary);
if (!file) return;
char buffer[BUF_SIZE];
while (file.read(buffer, BUF_SIZE) || file.gcount() > 0) {
size_t n = static_cast(file.gcount());
process_chunk(buffer, n); // 自定义处理函数
if (file.eof()) break;
}
需要更高吞吐？试试 mmap（Linux/macOS）或 CreateFileMapping（Windows）
内存映射不是“把整个文件装进内存”，而是建立虚拟地址映射，按需触发 page fault 加载——这比手动 read/write 更贴近现代 SSD/NVMe 的并行读取能力。但代价是：你得自己管理映射范围、处理信号（如 SIGBUS）、且跨平台封装成本高。
立即学习“C++免费学习笔记（深入）”；
- Linux 下用
mmap(nullptr, len, PROT_READ, MAP_PRIVATE, fd, offset)，len不必等于文件大小，可分段映射 - Windows 需先
CreateFile得句柄，再CreateFileMapping+MapViewOfFile - 注意：映射区域不可写时，传
PROT_READ或PAGE_READONLY；若后续要修改，必须用MAP_SHARED和PAGE_READWRITE -
mmap失败返回MAP_FAILED（不是nullptr），别漏判
跳过某段内容？别用 seekg 频繁定位
对机械硬盘或某些网络文件系统，seekg 后紧跟 read 会产生大量寻道延迟。如果目标是“跳过前 100MB 解析后续”，更高效的做法是：用 read 循环丢弃数据，而不是反复 seek —— 因为连续读比随机 seek 快 3~10 倍。
- 丢弃数据时，复用同一栈缓冲区（如 8KB），避免堆分配开销
- 若需精确跳转到某行（如 CSV 第 100 万行），先用
read找换行符，而不是逐字节get() -
seekg在std::ios::binary模式下是字节偏移，安全；但在文本模式下行为未定义，禁用
超大文件处理真正的复杂点不在“怎么读”，而在“怎么定义‘一块’”：是固定字节数？按行？按 JSON 对象边界？这些语义解析逻辑一旦和底层读取耦合，就很难测试和复用。宁愿多一层抽象，把“块提取”和“块处理”拆开。
