setvbuf不能用于C++流对象，因其仅作用于FILE，对std::ofstream等无效；强行调用std::filebuf的setvbuf会触发未定义行为，因filebuf已接管缓冲逻辑。
setvbuf 为什么不能用在 C++ 流对象上
setvbuf 是 C 标准库函数，只对 FILE* 生效，对 std::ofstream、std::ifstream 等 C++ 流对象完全无效。强行对 std::ofstream::rdbuf() 返回的 std::filebuf* 调用 setvbuf 不仅没效果，还可能触发未定义行为——因为 std::filebuf 内部已接管缓冲逻辑，且其底层 FILE* 可能已被设为无缓冲或由系统管理。
常见错误现象：
- 调用 setvbuf(fp, buf, _IOFBF, size) 后，写入仍频繁落盘（strace 显示大量 write() 系统调用）
- 在 C++ 流构造后试图用 freopen 或 setvbuf “接管”底层文件描述符，结果流行为异常（如部分写入丢失、flush() 失效）
真正可控的缓冲方式：用 std::filebuf::pubsetbuf
std::filebuf::pubsetbuf 是 C++ 标准中唯一可显式设置底层缓冲区的接口，但它有严格限制：必须在文件打开前调用，且仅对某些实现（如 libstdc++）在特定模式下生效；libc++（Clang 默认）通常直接忽略该调用。
实操建议：
- ✅ 先分配缓冲区内存：char buf[65536];
- ✅ 构造 std::filebuf 对象，立即调用：fb.pubsetbuf(buf, sizeof(buf));
- ✅ 再调用 fb.open("out.txt", std::ios_base::out);
- ❌ 不要在 std::ofstream 构造完成后尝试获取并修改其 rdbuf() —— 此时文件已打开，pubsetbuf 返回 nullptr，调用无效
注意：pubsetbuf 的缓冲区生命周期必须长于 filebuf 对象；若用栈内存（如上例），确保 filebuf 不会比缓冲区先析构。
更可靠的选择：绕过 iostream，直接用 FILE* + setvbuf
如果目标是确定性缓冲控制（比如固定 128KB 全缓冲），放弃 std::ofstream，改用 C 风格 I/O 更直接、可预测。
立即学习“C++免费学习笔记（深入）”；
使用场景：
- 日志批量写入、导出中间数据、离线处理等对性能敏感但无需格式化功能的场合
- 需要与 C 库（如 zlib、libpng）混用文件句柄时
实操步骤：
- 用 fopen("data.bin", "wb") 获取 FILE*
- 立即调用 setvbuf(fp, nullptr, _IOFBF, 131072)（第二个参数为 nullptr 让 libc 自行分配）
- 用 fwrite() / fputs() 写入，fclose() 或 fflush() 触发实际落盘
- 若需兼容 C++ RAII，可封装为轻量类，析构时调用 fclose()
性能影响：
- 缓冲区太小（如 4KB）会导致频繁 flush，抵消缓冲收益
- 缓冲区太大（如 >1MB）可能增加单次 write 延迟，且占用更多 RSS；一般 64–256KB 是较优区间
磁盘 IO 频率没降？检查这些隐性干扰
即使正确设置了缓冲，strace -e write 仍看到高频 write()，大概率不是缓冲失效，而是其他机制在干预：
常见原因：
- 文件以 O_SYNC 或 O_DSYNC 标志打开（std::ofstream 无法指定，C 的 open() + fdopen() 才能控制）
- 使用了 std::endl —— 它强制 flush()，等价于 "\n" + flush()；换成 "\n" 可避免意外刷盘
- 文件系统挂载参数含 sync 或 barrier=1（尤其在虚拟机或容器中）
- fclose() 或流析构时发生一次大 flush，误以为“一直没缓冲”，其实只是延迟到了最后
验证方法：
- 用 strace -e trace=write,fsync,fdatasync -s 16 ./a.out 区分是 write() 还是同步调用导致 IO
- 对比 std::ofstream 和 FILE* 版本的 write() 调用次数，确认差异来源
缓冲区大小和时机终究是权衡：太激进的缓冲会拖慢错误反馈（如磁盘满时延迟报错），而绕过 iostream 虽可控，却丢掉了类型安全和异常支持。真要压榨 IO 性能，往往得接受这种取舍。
