直接赋值cout.rdbuf(file.rdbuf())常失效，因C++11起禁止对全局流对象非const赋值，须用缓冲区交换；正确做法是先保存原streambuf*，再替换并确保文件流生命周期长于重定向期，最后显式恢复。
为什么直接赋值 cout.rdbuf() 会失效
很多人试过 cout.rdbuf(file_stream.rdbuf()) 后发现输出仍打到控制台，根本原因是：标准流对象（如 cout）的 rdbuf() 返回的是 std::streambuf*，但 C++11 起禁止对 cout 这类全局流对象调用非 const 版 rdbuf() 赋值——编译器可能静默忽略，或在某些 STL 实现中触发未定义行为。
真正生效的方式是缓冲区交换（swap），而非覆盖。标准库允许通过 std::basic_ios::rdbuf() 的重载版本交换底层缓冲区指针，前提是目标 streambuf 生命周期必须长于 cout。
- 不要用
cout.rdbuf(my_file.rdbuf())—— 这不是交换，且多数实现拒绝执行 - 必须用
cout.rdbuf(my_file.rdbuf())的返回值保存原缓冲区，再在恢复时换回 -
my_file必须是std::ofstream或其他带有效streambuf的流，且不能是局部临时对象
如何安全地把 cout 重定向到文件并可恢复
核心操作是「保存旧 buffer → 替换为文件 buffer → 恢复时换回」。关键点在于：旧 buffer 不能被析构，否则恢复后 cout 写入野指针。
下面是最小可靠写法：
立即学习“C++免费学习笔记（深入）”；
std::ofstream log_file("output.txt");
std::streambuf* original_cout_buf = std::cout.rdbuf(log_file.rdbuf());
// 此时所有 cout << 都写入 output.txt
std::cout << "Hello to file!" << std::endl;
// 恢复前必须先 flush，否则缓冲区内容可能丢失
log_file.flush();
std::cout.rdbuf(original_cout_buf); // 换回原始 stdout buffer
-
original_cout_buf必须声明在作用域外层，避免提前销毁 -
log_file不能是临时对象（如std::ofstream("x.txt")），否则其rdbuf()在语句结束即失效 - 恢复前调用
log_file.flush()或std::cout.flush()，否则最后一段输出可能卡在缓冲区没落盘
重定向期间 cerr 和 clog 会受影响吗
不会。cerr 和 clog 是独立流对象，各自持有自己的 streambuf。修改 cout.rdbuf() 只影响 cout 的输出路径。
- 若需同时重定向
cerr，必须单独调用cerr.rdbuf(...) -
clog默认行缓冲，cerr默认无缓冲，重定向后它们的缓冲策略不变，但目标设备变为文件 —— 注意这可能导致日志延迟出现 - 如果用同一
ofstream接管cout和cerr，要确保该文件流打开时用了std::ios::out | std::ios::app，否则后者会覆盖前者内容
跨平台兼容性与常见崩溃点
Windows 下用 freopen 看似简单，但和 C++ 流混用极易导致 double-close 或缓冲区错乱；而 rdbuf() 交换是纯 C++ 方式，POSIX 和 MSVC 均支持，但有细节差异：
- Linux / GCC：
std::cout.rdbuf()返回的原始 buffer 是__gnu_cxx::stdio_sync_filebuf，可安全交换 - MSVC：要求
log_file必须在cout.rdbuf()调用前已打开，且不能中途 close，否则后续写入触发 access violation - 最易踩的坑：在函数返回前忘记恢复
cout.rdbuf()—— 后续所有cout输出将写入已关闭/析构的文件流，程序可能 crash 或静默丢数据
缓冲区交换本身不涉及系统调用，性能开销极小，但务必确保生命周期管理严格匹配：文件流对象生存期 ≥ 重定向持续时间 ≥ 恢复调用时机。
