std::cout.rdbuf()交换缓冲区是最轻量可控的日志重定向方式，但需确保文件流生命周期长于重定向期、注意线程安全并合理控制flush时机，否则易致日志丢失或崩溃。
直接结论：用 std::cout.rdbuf() 交换流缓冲区是最轻量、最可控的方式，但必须注意生命周期和线程安全，否则日志会丢失或崩溃。
为什么不能只用 freopen()？
很多人第一反应是 freopen("log.txt", "w", stdout)，但它在 C++ 中有严重隐患：
- C 风格重定向不保证与
std::cout同步，尤其混用printf和std::cout 时容易乱序或丢输出 - Windows 下若程序异常退出（如未调用
fflush(stdout)），缓冲区内容可能根本没写入文件 -
freopen会关闭原stdout文件描述符，后续再想切回控制台就麻烦了（需保存原始 fd）
std::cout.rdbuf() 交换的正确姿势
核心是用一个 std::ofstream 的缓冲区替换 std::cout 的默认缓冲区，且必须确保文件流对象的生命周期长于重定向期：
- 绝不能写成临时对象：
std::cout.rdbuf(std::ofstream("log.txt").rdbuf())—— 临时ofstream析构后缓冲区失效，后续cout行为未定义 - 必须持有持久对象：声明为全局、静态，或封装在 RAII 类中
- 记得恢复原始缓冲区（尤其调试时），否则程序退出前日志可能没 flush
示例（最小可行）：
立即学习“C++免费学习笔记（深入）”；
std::ofstream log_file("app.log");
std::streambuf* original_cout = std::cout.rdbuf(log_file.rdbuf());
// ... 输出内容
std::cout << "Hello to file" << std::endl;
// 恢复（可选，但推荐）
std::cout.rdbuf(original_cout);
log_file.flush(); // 确保写入磁盘
多线程下 std::cout 重定向的坑
多个线程同时写 std::cout 时，仅交换 rdbuf 不解决线程竞争问题：
-
std::ofstream默认不是线程安全的；多个线程往同一个ofstream写，可能破坏文件内容 - 即使加锁，也别在锁内调用
std::cout —— 它内部还可能触发格式化、locale 查找等非原子操作 - 更稳妥的做法：自己实现带锁的日志函数，或改用
std::osyncstream（C++20）
C++20 示例（自动同步）：
std::ofstream log_file("app.log");
std::osyncstream synced_cout(log_file);
synced_cout << "Thread-safe line" << std::endl; // 自动加锁 + flush
重定向后 std::endl 和 \n 的区别变大了
原本在控制台几乎无感，但重定向到文件后：
-
\n只换行，不强制刷新缓冲区 → 日志可能滞留在内存里，进程崩溃就丢了 -
std::endl=\n+flush()→ 每次都刷盘，性能差（尤其高频日志） - 折中方案：用
\n，定期手动log_file.flush()；或设置log_file.setf(std::ios::unitbuf)开启行缓冲（但仅对std::endl生效）
真正难的不是交换 rdbuf 这一行代码，而是控制好文件对象的生存期、处理好线程并发、以及理解 flush 时机 —— 这三点漏掉任一，日志就可能静默失败。
