不能直接用fread一次性读完大文件，因32位程序无法分配4GB单块缓冲区，64位下也易阻塞线程、触发OOM，且多数场景无需全量驻留内存；应分块读取并正确处理边界与EOF。
为什么不能直接用 fread 一次性读完大文件
内存不够是硬限制。比如一个 4GB 的日志文件，在 32 位程序里根本无法分配单块 4GB 缓冲区；即使在 64 位下，一次性加载也会阻塞主线程、拖慢响应，还可能触发系统 OOM Killer。更关键的是，多数场景（如校验、过滤、流式解析）根本不需要全量驻留内存。
用 fseek + fread 分块读取的可靠写法
核心是控制每次读取的字节数，并正确处理边界和 EOF。注意：不能依赖 fread 返回值等于请求长度来判断是否读完——最后一块通常不足。
-
fseek(fp, offset, SEEK_SET)定位到起始位置，offset必须是long类型，超 2GB 文件需确保编译器支持_FILE_OFFSET_BITS=64（Linux）或使用_fseeki64（Windows） - 每次调用
fread(buf, 1, chunk_size, fp)后，检查返回值size_t n = fread(...)，它表示**实际读到的字节数**，可能为 0（EOF 或出错） - 读完一块后不要立刻
fseek到下一块——应基于本次n计算下一次offset，避免因换行符、编码边界等导致跳过数据
FILE* fp = fopen("huge.log", "rb");
if (!fp) return;
const size_t chunk_size = 64 * 1024; // 64KB
char* buf = new char[chunk_size];
size_t offset = 0;
while (true) {
fseek(fp, offset, SEEK_SET);
size_t n = fread(buf, 1, chunk_size, fp);
if (n == 0) break; // EOF or error
// 处理 buf[0..n-1]
process_chunk(buf, n);
offset += n; // 下一块从当前位置开始，不跳字节
}
delete[] buf;
fclose(fp);
用 std::ifstream 分块时必须避开的坑
std::ifstream 默认启用缓冲，但 read() 在二进制模式下行为与 C 风格一致；问题多出在文本模式（自动换行转换）、异常掩码未关闭、以及 gcount() 被忽略。
- 务必调用
file.open("...", std::ios::binary)，否则 Windows 下\r\n可能被误转为\n，破坏原始字节偏移 - 不要用
file >>或getline()处理大文件——它们内部会反复调用sbumpc()，性能极差且无法控制块大小 - 每次
read(buf, size)后，必须用file.gcount()获取真实读取字节数，file.fail()和file.eof()需配合判断：仅当gcount() == 0 && !fail()才是干净 EOF
分块大小选 64KB 还是 1MB？看 I/O 模式和设备
不是越大越好。机械硬盘随机读取 1MB 块可能比顺序读慢 20%，而 SSD 上差异不大；但内存拷贝开销、cache line 对齐、以及下游处理单元（如解压、加密）的吞吐瓶颈更关键。
立即学习“C++免费学习笔记（深入）”；
- 纯顺序扫描（如统计行数）：64KB ~ 256KB 平衡了系统调用开销和 cache 效率
- 需要按固定结构解析（如 protobuf record）：块尾需预留至少一个完整 record 长度，避免跨块截断，此时建议 1MB + 边界对齐逻辑
- 网络文件系统（NFS/SMB）：小块（8KB~32KB）更稳定，大块易触发 timeout 或重传
真正难的不是怎么读，而是怎么定义“块”——是按字节切分，还是按逻辑记录切分；后者要求预读+回退机制，容易漏掉跨块的换行或帧头。
