必须关闭同步以避免输出卡住或丢失：重定向前调用 std::ios::sync_with_stdio(false)，禁用C/C++流缓冲同步；否则混用printf与cout易导致延迟或日志丢失。
std::cout 重定向到文件前必须关闭缓冲同步
直接用 std::freopen 或 std::cout.rdbuf() 重定向后，如果没关掉 std::ios::sync_with_stdio，输出可能卡住、延迟写入，甚至丢失最后一段日志。这是因为 C++ 流默认与 C stdio 同步，而重定向后两套缓冲机制容易打架。
实操建议：
- 在重定向前加一句
std::ios::sync_with_stdio(false)，禁用同步（注意：此后不能再混用printf和std::cout） - 若需保留 C 风格输出，改用
std::freopen("log.txt", "a", stdout)，它会自动接管std::cout（但仅限于未调用std::ios::sync_with_stdio(true)的情况） - 重定向后建议调用
std::cout 强制行缓冲（或用 <code>std::cout 换行触发刷新），避免程序异常退出时日志不全
用 rdbuf() 重定向更可控，但要注意生命周期
std::cout.rdbuf() 是最灵活的方式，能精确绑定到自定义 std::filebuf，支持带缓冲的异步写入，也方便后续切回终端。但它对对象生命周期敏感——一旦底层 std::filebuf 析构，std::cout 就会失效，甚至导致 crash。
常见错误现象：std::cout 突然不输出，或程序在 exit 时 segfault。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 把
std::filebuf声明为全局或静态变量，确保其生命周期覆盖整个程序运行期 - 不要用临时
std::ofstream的rdbuf()（例如std::cout.rdbuf(std::ofstream("log.txt").rdbuf())是典型错误） - 示例安全写法：
std::filebuf log_buf; log_buf.open("app.log", std::ios_base::out | std::ios_base::app); std::streambuf* old_buf = std::cout.rdbuf(&log_buf);
Windows 下 freopen 重定向 stdout 可能被 IDE 截断
Visual Studio 默认调试器不显示重定向后的 stdout 输出，且某些版本（如 VS2019+）会拦截 freopen 调用，导致日志文件为空或只写入少量内容。这不是代码错，而是 IDE 运行环境干扰。
使用场景：本地开发调试阶段频繁查看日志，又不想改代码。
实操建议：
- 编译时加预处理器定义
_CRT_SECURE_NO_WARNINGS，避免freopen被安全警告抑制 - 调试时改用命令行启动（
your_app.exe > log.txt 2>&1），绕过 IDE 输出捕获 - 若坚持用
freopen，务必在main()开头立即调用，并检查返回值是否为nullptr（失败时返回NULL）
带缓冲的日志需要手动 flush，尤其在信号处理中
程序收到 SIGINT（Ctrl+C）或崩溃前，缓冲区里未刷出的内容会永久丢失。标准库不会自动帮你 flush std::cout 关联的文件缓冲区。
性能影响：频繁 std::cout 会显著拖慢日志性能；完全不 flush 则可靠性差。
实操建议：
- 注册信号处理器，在
SIGTERM/SIGINT中调用std::cout （注意：<code>std::flush是 async-signal-safe 的，但std::cout 不是——所以只在信号 handler 里做 flush，别写新日志） - 对关键日志行末尾显式加
（它等价于输出 <code>\n+flush），比更稳妥 - 若用多线程打日志，
std::cout本身不是线程安全的，必须加锁或改用独立std::ofstream对象
真正麻烦的从来不是“怎么写进文件”，而是“怎么确保每条都写进去、不丢、不错序、不崩”。缓冲策略、对象生命周期、信号安全、线程安全——这四点漏掉任一个，上线后查日志就像盲人摸象。
