直接读大文件崩溃因一次性分配几GB内存触发OOM；安全做法是用4KB–64KB缓冲区配合read()和gcount()分块读取，禁用eof()循环，二进制模式打开，避免栈溢出、UTF-8截断及错误恢复失效。
为什么 std::ifstream 直接读整个大文件会崩
因为默认用 std::string::resize() 或 std::vector::resize() 一次性分配几 GB 内存，触发 OOM 或系统杀进程；operator>> 和 getline() 在超长行或二进制乱码时还会卡死或跳过数据。
真正安全的做法是放弃“全读进内存”这个念头，改用固定缓冲区循环搬运：
- 缓冲区大小建议在
4096（一页）到65536（64KB）之间，太小频繁 syscall，太大无意义 - 必须用
read()配合gcount()，不能依赖eof()判定结束——文件末尾可能刚好处在块边界，eof()还没置位 - 二进制模式打开：构造
std::ifstream file("path", std::ios::binary)，否则 Windows 下\r\n被静默转成\n，长度错乱
read() 分块读取的正确写法
核心就三步：分配栈缓冲、调用 read()、检查实际读取字节数。别信网上那些用 while (!file.eof()) 包裹 read() 的写法——最后一次读失败后 eof() 才为真，但此时你已经多跑了一次循环。
char buf[65536];
while (file.read(buf, sizeof(buf))) {
process(buf, sizeof(buf));
}
if (file.gcount() > 0) {
process(buf, file.gcount()); // 处理最后一块不足 size 的数据
}
gcount() 返回上一次 read() 实际读到的字节数，哪怕只读了 1 字节也得处理；如果 read() 因错误（如磁盘断开）返回，gcount() 为 0，此时应检查 file.fail() 或 file.bad()。
立即学习“C++免费学习笔记（深入）”；
mmap 比 read() 快吗？什么时候该用
在 Linux/macOS 上，mmap 对超大文件（>512MB）随机访问场景确实更快，但代价是：需要手动处理 MAP_PRIVATE/MAP_SHARED、页对齐、信号中断（SIGBUS）、以及 Windows 下要用 CreateFileMapping + MapViewOfFile 完全不同 API。
除非你满足以下全部条件，否则优先用 read()：
- 文件大小稳定且远大于物理内存（避免 swap）
- 访问模式是稀疏、跳跃式（比如解析日志中特定时间戳段）
- 项目已封装跨平台 mmap 抽象层，或只跑 Linux
- 能接受首次访问某页时的缺页异常延迟（毫秒级）
简单顺序扫描，read() + 合理缓冲区，性能差距几乎不可测，还省心。
避免踩坑：缓冲区、编码、错误恢复
常见翻车点不是算法，而是细节：
- 用
std::vector替代栈数组？小心栈溢出——64KB 栈空间在某些嵌入式或限制线程栈的环境里直接 crashbuf(65536) - 文本文件别假设 UTF-8 单字节分块安全：
read()可能截断多字节字符，后续std::string_view解析会出错；需在块边界做 UTF-8 完整性校验或改用按行读（但行长度不可控） - 读取中磁盘拔掉？
read()返回 0 并设failbit，此时file.clear()无法恢复，只能 close 后重试 - 别把
file.peek() == EOF当作结束判断——它不推进读位置，且对管道/设备文件行为未定义
大文件处理没有银弹，关键是把“块大小”“错误分支”“内存生命周期”三个变量钉死，其余都是围绕它们的微调。
