最直接的大文件分块读取方式是用 std::ifstream::read() 配合二进制模式与 gcount() 检查实际字节数，块大小建议 4KB–64KB，避免 operator>>/getline；mmap() 仅适合只读随机访问场景；Windows 超 4GB 文件推荐 CreateFile+ReadFile；处理逻辑需预留内存、避免频繁分配。
用 std::ifstream 配合 read() 做固定大小分块读取最直接
大文件不一次性加载进内存，是避免 OOM 和提升响应的关键。C++ 标准库里最可控的方式就是用 std::ifstream 的 read() 成员函数手动控制每次读多少字节。
常见错误是用 operator>> 或 getline() 处理大二进制/无结构文本文件——它们内部有缓冲和解析开销，还可能因换行符或空格提前截断，完全不适合“分块”这个目标。
- 块大小建议设为 4KB～64KB（如
4096、65536），太小导致系统调用频繁，太大可能挤占其他内存 - 务必检查
gcount()返回值：它才是本次实际读到的字节数，read()本身不抛异常也不自动补零 - 打开文件时加
std::ios::binary，否则 Windows 下遇到\x1A会误判 EOF
std::ifstream file("huge.bin", std::ios::binary);
file.seekg(0, std::ios::end);
size_t total = file.tellg();
file.seekg(0);
const size_t chunk_size = 65536;
std::vector<char> buf(chunk_size);
while (file.read(buf.data(), chunk_size)) {
process_chunk(buf.data(), chunk_size);
}
// 处理最后一块（不足 chunk_size）
if (file.gcount() > 0) {
process_chunk(buf.data(), static_cast<size_t>(file.gcount()));
}
用 mmap() 替代 read() 能绕过内核拷贝，但只适合只读+随机访问场景
Linux/macOS 上 mmap() 把文件直接映射成内存地址，省去 read() 的用户态/内核态数据拷贝，理论吞吐更高。但它不是万能加速器，用错反而更慢。
典型误用：对一个只顺序读一遍的大日志文件做 mmap()，结果触发大量缺页中断，比 read() 还卡；或者在小内存机器上映射几十 GB 文件，直接被 OOM killer 干掉。
立即学习“C++免费学习笔记（深入）”；
-
mmap()后仍需按需访问内存区域，不访问就不会加载物理页——别以为“映射了就等于全读进来了” - 必须用
MAP_PRIVATE+PROT_READ，写入需求要另说，且 Windows 对应 API（CreateFileMapping）行为差异大 - 记得
munmap()，尤其在长生命周期程序中，否则内存泄漏不易察觉
Windows 下 CreateFile + ReadFile 比 fopen 更稳，尤其超 4GB 文件
Visual C++ 的 std::ifstream 在处理大于 4GB 的文件时，某些旧版本 runtime 会因 32 位偏移量截断 tellg() 或 seekg()，导致分块错位。原生 Win32 API 没这问题。
关键点不在“多快”，而在“不丢字节”。比如你按每 1MB 分块，第 1024 块本该从位置 1048576000 开始，但 tellg() 返回 0，后面全乱。
- 用
CreateFile时指定FILE_ATTRIBUTE_NORMAL和FILE_FLAG_SEQUENTIAL_SCAN，帮系统预判访问模式 -
ReadFile的lpNumberOfBytesRead参数必须检查，不能只看返回值 TRUE/FALSE - 路径要用宽字符（
L"..."），否则中文路径在ANSI模式下直接失败
分块后处理逻辑卡住？先确认是不是 std::vector::resize() 或字符串拼接拖慢了
很多人把 IO 优化做完，发现整体速度没变——问题常出在“处理块”的环节。比如用 std::string += 累积解析结果，或反复 resize() 一个 vector，触发多次内存重分配。
这不是 IO 问题，是内存模式问题。尤其当块大小固定、处理逻辑确定时，提前预留空间几乎零成本。
- 如果每块解析出 N 条记录，且 N 可估算，就用
results.reserve(expected_total)开局 - 避免在循环里构造临时
std::string再转std::vector<uint8_t></uint8_t>，直接用std::string_view观察原始 buffer 片段 - 调试时加个
clock()或std::chrono打点，确认耗时真在 IO 层，还是卡在process_chunk()里
