setvbuf仅对FILE*有效，对std::fstream等C++流对象调用必失败；唯一生效路径是fopen后立即调用，且需满足二进制模式、无前置I/O、缓冲区生命周期覆盖全程等硬性前提。
setvbuf 只对 FILE* 有效，std::fstream 调用必失败
直接对 std::ofstream 或 std::ifstream 对象调用 setvbuf 是无效的——它根本不接受 std::filebuf* 或任何 C++ 流对象。常见错误是试图从 f.rdbuf() 拿到私有成员（如 _M_file 或 __filebuf_fd()）再传给 setvbuf，这在 libc++ 下根本不存在，在 libstdc++ 下属于未定义行为，且流构造时底层 FILE* 已完成初始化和首次 I/O，setvbuf 调用会静默忽略或返回 -1。
真正能生效的唯一路径：纯 C 风格 FILE*，且满足三个硬性前提：
-
fopen返回非空指针后，**立刻**调用setvbuf，中间不能有任何 I/O（包括fseek、feof、ferror） - 打开模式必须是二进制（
"rb"/"wb"），文本模式（尤其 Windows）可能导致setvbuf被忽略 - 缓冲区指针（第二个参数）生命周期必须覆盖整个
fclose过程
自定义缓冲区必须全程有效，栈变量极易崩溃
传给 setvbuf 的缓冲区指针若指向栈内存（如 char buf[65536]），只在当前函数作用域内安全；一旦函数返回、buf 被销毁，后续 fwrite 或 fread 就会写入野指针——这不是“偶尔出错”，而是确定性的未定义行为，常表现为段错误或数据损坏。
安全做法分场景：
立即学习“C++免费学习笔记（深入）”；
- 短生命周期流（如单个函数内打开-读写-关闭）：可用
static char buf[65536]，避免栈分配 - 需跨函数或长期持有：用
char* buf = new char[65536]，并在fclose(fp)**之后** 才delete[] buf - 严格对齐要求（musl、ARM 等）：改用
aligned_alloc(4096, 65536)或posix_memalign(&buf, 4096, 65536) - 最小尺寸注意：
size必须 ≥ 256 字节（glibc 要求），否则可能静默降级为默认缓冲
_IOLBF 对文件流完全无效，别指望它按行刷盘
设 mode = _IOLBF 并传入自定义缓冲区，对普通文件流（如 fopen("data.txt", "w")）毫无意义。POSIX 明确规定：当流不关联终端时，_IOLBF 行为等同于 _IOFBF（全缓冲）。你写入 100 行，只要没手动 fflush 或关闭流，内容就一直卡在缓冲区里。
常见误判现象：
- 重定向
stdout到文件后仍设_IOLBF，以为能“实时看到日志” → 实际仍是全缓冲 - 在日志系统中依赖换行符自动刷新 → 必须显式
fflush(fp)或用setvbuf(fp, nullptr, _IONBF, 0)（但性能极差） - Windows 下
_IOLBF基本被忽略，行为不可控
真要行缓冲写入文件，唯一可靠方式：每次 fputs 后紧跟 fflush，别寄希望于 mode 参数。
setvbuf 传 NULL 时 size 会被截断，且无法中途更换
用 setvbuf(fp, nullptr, _IOFBF, 65535) 看似省事，但 glibc 会把 size 向下取整为偶数（即实际用 65534），musl 可能进一步对齐到页边界。更关键的是：一旦 setvbuf 成功，缓冲策略就固定了——你不能在写入一半后切到无缓冲，也不能扩大缓冲区。想换策略，只能 fclose 后重新 fopen + setvbuf。
几个硬约束必须记住：
-
_IONBF模式下，第二个参数**必须为nullptr**，传非空指针行为未定义 -
_IONBF不等于“立即落盘”，它只是跳过 libc 缓冲层，write()系统调用仍受内核 page cache 影响，强制刷盘需额外fsync() - 缓冲区大小不是越大越好：超过 256 KB 后吞吐提升极小，反而增加首次分配延迟和内存碎片
最易被忽略的一点：混用 C 和 C++ 流（比如 printf 和 std::cout 共享 stdout）时，setvbuf(stdout, ...) 会破坏 C++ 流的同步逻辑，导致输出乱序或卡死——除非提前调用 std::ios_base::sync_with_stdio(false)，且该调用必须在任何输出之前。
