setvbuf必须在fopen后、任何I/O操作前调用，否则失效；常见错误是fopen后执行fprintf等再调用，此时返回非零且行为未定义；正确顺序为fopen→setvbuf→其他I/O。
setvbuf 必须在 fopen 后、任何 I/O 前调用，否则直接失效
调用 setvbuf 失败的最常见原因，不是参数写错，而是时机不对。只要对 FILE* 执行过哪怕一次 fread、fwrite、fprintf、fflush，甚至 feof 或 ferror，缓冲区就已隐式初始化，setvbuf 会返回非零值且后续行为未定义。
- 错误顺序：
fopen→fprintf→setvbuf（完全无效） - 正确顺序：
fopen→setvbuf→ 其他所有 I/O 操作 - Windows 下尤其注意：必须用
"rb"或"wb"二进制模式打开，文本模式（"r"/"w"）可能导致setvbuf被忽略 - 务必检查返回值：
if (setvbuf(fp, buf, _IOFBF, size) != 0) { /* 处理失败 */ }
_IOFBF / _IOLBF / _IONBF 三个模式的实际表现差异
别被名字误导。_IOLBF 对文件流基本没用，_IONBF 不是“实时落盘”，而 _IOFBF 才是绝大多数场景的唯一合理选择。
-
_IOFBF（全缓冲）：数据攒满才刷出；适合大块顺序读写；传自定义缓冲区或NULL均可；推荐大小 64–256 KB -
_IOLBF（行缓冲）：POSIX 规定其在非终端流（如文件）上退化为_IOFBF；Windows 下更直接无视换行逻辑；**别为文件流设这个** -
_IONBF（无缓冲）：每次fwrite都触发write()系统调用；性能极差；唯一合法调用是setvbuf(fp, nullptr, _IONBF, 0)；第二个参数必须为nullptr，否则未定义
自定义缓冲区的内存必须全程有效且对齐
传给 setvbuf 的缓冲区指针一旦失效，后续 fwrite 就可能写入野地址——崩溃不一定立刻发生，但后果不可控。
- 栈上分配（如
char buf[65536]）只适用于短生命周期：确保fclose(fp)在同一作用域内执行 - 跨函数/长期使用必须堆分配：
char* buf; posix_memalign(&buf, 64, size);，并在fclose(fp)之后再free(buf) - 对齐要求不能忽略：musl、某些 ARM libc 或严格平台要求 64 字节或页对齐（
alignas(4096)），否则setvbuf可能静默失败 - 最小尺寸建议 ≥
BUFSIZ（通常 8192）；小于 256 字节时，glibc 可能降级为默认缓冲
std::fstream 无法用 setvbuf 控制底层缓冲区
试图从 std::ofstream 拿 FILE* 再调 setvbuf 是危险操作：标准不保证其底层 FILE* 可访问，且构造时已触发 I/O 初始化，缓冲区状态早已锁定。
立即学习“C++免费学习笔记（深入）”；
-
rdbuf()->_file是 libstdc++ 私有成员，libc++ 根本不存在；强行访问触发未定义行为 -
pubsetbuf行为依赖实现，非标准保证，多数场景下无效或静默忽略 - 真正可控方案只有两个：
fopen + setvbuf + fread/fwrite，或接受std::fstream默认缓冲（通常已足够） - 若需 RAII 和控制力兼顾，应封装
FILE*（如用std::unique_ptr<file int></file>配合fclose），而非强套 iostream
缓冲区大小不是越大越好，超过系统页大小（4 KB）后吞吐收益快速衰减；真正卡性能的往往是磁盘寻址、锁竞争或 flush 频率，而不是缓冲区本身。最容易被忽略的，是缓冲区内存的生命周期和对齐——这两点出问题，程序不会报错，但会在某个看似无关的 fwrite 调用里突然崩掉。
