c++oding="utf-8" ?>
std::ifstream 默认 buffer 效率低是因为其内置 buffer 仅4kb–8kb，读大文件时频繁系统调用和内存拷贝；setbuf() 不可靠，真正高效方案是继承 std::filebuf 自定义 underflow() 并使用大页对齐 buffer。
为什么 std::ifstream 默认 buffer 效率低？
默认情况下，std::ifstream 使用的内部 buffer 通常只有 4KB–8KB（具体取决于标准库实现），且无法通过公开接口直接扩容。小 buffer 在读取大文件时会频繁触发系统调用 read() 和用户态内存拷贝，成为瓶颈；尤其在顺序读取 GB 级日志或二进制数据时，实测 I/O 吞吐可能比系统原生 read() 低 30%–50%。
关键点在于：C++ 标准流的 buffer 是由 std::streambuf 子类管理的，而 std::filebuf 虽然支持 setbuf()，但该函数仅在 stream 未打开时有效，且多数 libstdc++/libc++ 实现中对非 nullptr 参数的支持是“名义上的”——实际可能被忽略或仅用于调试。
setbuf() 为何经常失效？
调用 setbuf() 失败的常见现象是：buffer 未生效、仍走默认小 buffer、甚至程序崩溃（若传入栈内存地址）。根本原因是：
-
setbuf(ptr, size)必须在open()前调用，且ptr必须是生命周期覆盖整个 stream 的内存（堆分配最稳妥） - libstdc++（GCC）从 7.1+ 开始，
setbuf()对std::filebuf已标记为 deprecated，实际逻辑常跳过自定义 buffer - libc++（Clang）虽保留支持，但要求
size是 2 的幂，且最小值通常为 512 字节；小于该值会被截断，导致 buffer 实际大小远低于预期
所以别依赖 setbuf()——它不是稳定可移植的提速手段。
真正可靠的方案：继承 std::filebuf 并重写 underflow()
要完全控制 buffer 行为，必须定制 std::streambuf。核心是接管底层字节供给逻辑，绕过默认的惰性填充策略。以下是最简可行实现：
class custom_filebuf : public std::filebuf {
std::vector<char> buf_;
public:
explicit custom_filebuf(size_t bufsize = 64 * 1024) : buf_(bufsize) {}
<p>protected:
int_type underflow() override {
if (gptr() >= egptr()) {
// 触发底层 read，填满自定义 buffer
auto n = sys<em>read(fd(), buf</em>.data(), buf_.size());
if (n type::eof();
setg(buf.data(), buf<em>.data(), buf</em>.data() + n);
}
return traits_type::to_int_type(*gptr());
}
};</p></char>
注意几个硬性细节：
- 必须用
sys_read()（Linux）或_read()（Windows）绕过 C 库缓冲，否则仍受 libc 层干扰 -
fd()是std::filebuf的 protected 成员，可直接访问底层文件描述符 -
setg()三参数分别设置 get-area 的起始、当前、结束指针；顺序不能错，否则gptr()返回空指针 - 不要在
underflow()中抛异常——流操作要求异常安全，失败应返回eof()
如何安全绑定到 std::istream？
不能直接把自定义 streambuf 传给 std::ifstream 构造函数（其构造函数不接受外部 streambuf*）。正确做法是：
- 用
std::istream构造函数接收streambuf*，并确保 lifetime 控制明确 - 避免裸指针悬挂：将
custom_filebuf和std::istream放在同一作用域，或用 RAII 包装
示例：
custom_filebuf fb(128 * 1024);
std::istream is(&fb);
fb.open("data.bin", std::ios::in | std::ios::binary);
// 此时 is 即可使用，且 buffer 完全由 fb 控制
容易被忽略的陷阱：
- 若文件以文本模式打开（
std::ios::in无binary），Windows 下 \r\n 换行符转换仍会发生，破坏二进制读取——务必加binary - 关闭流时，必须先调用
fb.close()，再让is和fb析构，否则 fd 可能被重复 close - 多线程读同一文件？
fd是共享的，需自行加锁；streambuf本身不保证线程安全
真正的性能提升来自 buffer 大小与磁盘块大小（通常是 4KB）的倍数关系，以及消除中间缓存层。但 buffer 不是越大越好——超过 L3 缓存容量（如 >2MB）反而因 TLB miss 导致性能下降。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
