fread整块读取反而比逐行慢，因需用户态手动切分换行符，不如getline等已优化方案；高效关键在避免重复拷贝、减少系统调用、适配访问模式。
为什么 fread 直接读整块反而比逐行慢？
因为超大文本文件通常含大量换行符，fread 一次读几 MB 进内存后，你还得自己扫描 \n 切分逻辑行——这步在用户态做，比内核+libc 已优化的 getline 或带缓冲的 std::istream 更容易写错、更难利用 CPU 预取和缓存行对齐。
真正高效不是“读得大”，而是“避免重复拷贝+减少系统调用+适配访问模式”。关键在缓冲区大小与页对齐、是否跳过解析、后续处理是否需要随机访问。
-
fread单次读取建议设为64 * 1024（64KB）或256 * 1024（256KB），避开 4KB 页边界竞争，又不至于让malloc分配大块内存引发碎片 - 不要用
sizeof(char) * N算缓冲区，直接写char buf[262144]——栈上分配小缓冲更快，但超过 1MB 必须new或mmap - 如果只统计行数或提取某列，别把整行存下来；用指针滑动扫描，遇到
\n就处理当前段，立刻丢弃
fread + 手动换行切分时怎么避免跨块截断？
缓冲区末尾刚好卡在 \n 中间（比如 "hel\nlo world" 被切成 "hel" 和 "lo world"），会导致解析错乱。这不是边界 bug，是设计缺失。
必须保留上一块末尾未完成的片段，拼到下一块开头。但别用 std::string 拼接——动态扩容有开销；用固定长度小缓冲（如 256 字节）暂存不完整行头即可。
立即学习“C++免费学习笔记（深入）”；
- 每次
fread前，先将上轮残留数据拷贝到新缓冲区头部，再从文件读剩余空间 - 扫描时，只在已读数据范围内找
\n；最后一行若无\n，就标记为“不完整行”，留待下次合并 - 别用
strchr(buf, '\n')——它可能扫过你预留的残留区，导致越界；用memchr(buf, '\n', actual_len)显式限定长度
什么时候该放弃 fread 改用 mmap？
当你要随机跳转查某一行、或反复回溯搜索（比如日志中按时间戳二分查找）、或文件稳定不被其他进程修改时，mmap 的零拷贝和虚拟内存映射优势才真正体现出来。否则，它只是多了一次 sys_mmap 调用，还可能触发缺页中断拖慢首读。
-
mmap后别直接拿char*当 C 字符串用——它不保证末尾有\0，且长度需你自己维护 - 用
MAP_PRIVATE而非MAP_SHARED，除非你真要和其他进程共享修改；前者更轻量，且不会因写时复制（COW）意外触发页分配 - Linux 下
mmap大于 2GB 文件需检查off_t是否为 64 位，否则lseek可能失败，mmap返回MAP_FAILED
Windows 上 fread 性能掉一半？关掉 _O_U16TEXT 和 CRT 缓冲
Windows 默认启用 Unicode 文本模式转换（_O_U16TEXT）和 CRT 层双缓冲，对纯 ASCII 日志文件是纯负担。即使你 fopen 用的是 "rb"，某些 VS 版本仍会偷偷启用宽字符路径逻辑。
- 显式调用
_setmode(_fileno(fp), _O_BINARY)关闭文本模式转换 - 用
setvbuf(fp, nullptr, _IONBF, 0)关掉 FILE* 自带缓冲，自己用fread控制——否则你读 64KB，CRT 可能先读 4KB 再 memcpy 给你，白费一次拷贝 - 避免
fopen_s，它默认带额外安全检查；直接用fopen+ferror检查错误更轻量
最易被忽略的其实是文件打开方式：用 "rb" 是基础，但 Linux 下还要加 O_DIRECT（需对齐）或 O_NOATIME 减少元数据更新；Windows 下得确认磁盘不是 FAT32（不支持 >4GB 单文件）。这些细节不处理，前面所有缓冲优化都打七折。
