必须用具名且生命周期覆盖全程的std::ofstream对象持有文件缓冲区，否则临时对象析构会导致cerr写入已释放内存而崩溃。
能重定向，但直接写 std::cerr.rdbuf((std::ofstream("err.log")).rdbuf()) 必崩——核心问题从来不是“怎么写”，而是“谁活得久”。
为什么 std::cerr.rdbuf() 一用就失效或崩溃
最常见错误是让 std::ofstream 对象变成临时变量或局部变量，比如在 if 块里声明、或直接构造后取 rdbuf()。一旦该对象析构，其内部 std::filebuf 被销毁，而 std::cerr 还在往已释放内存写，结果就是无输出、乱码、或 segfault。
- 必须用具名对象（全局、静态、或
main()开头的局部变量）持有std::ofstream，且它的生命周期必须覆盖所有std::cerr <<使用点 - 不能依赖 RAII 自动恢复：析构时调
std::cerr.rdbuf(old_buf)很危险——若 old_buf 已被其他线程/库修改，或程序异常退出，恢复逻辑根本不会执行 - 检查文件是否打开成功：
if (!log_file.is_open())，否则log_file.rdbuf()返回nullptr，后续std::cerr <<可能抛std::ios_base::failure
如何安全绑定 std::cerr 到文件并保持可用
关键三步：开文件 → 换 buffer → 强制刷盘。不推荐“自动恢复”，更推荐“进程级稳定绑定”。
- 用
std::ios_base::out | std::ios_base::app打开，避免覆盖历史日志；Windows 下路径含中文时，确保编译器和运行环境编码一致（如 UTF-8 +SetConsoleOutputCP(CP_UTF8)） - 调用
std::cerr.rdbuf(log_file.rdbuf())前，先保存原 buffer（auto old = std::cerr.rdbuf(...)），仅用于调试或测试中临时切换，非必选 - 加
std::cerr << std::unitbuf;：强制每条输出立即刷到磁盘，防止 crash 丢最后几行日志；不用std::endl（它 flush + \n，冗余） - 如果需要长期后台运行（如 daemon），建议在
main()开头完成重定向，并不再恢复——恢复反而容易引入竞态
std::cerr 重定向后，哪些输出会进文件、哪些不会
只捕获走 C++ iostream 层的 std::cerr <<，其它全部绕过。
立即学习“C++免费学习笔记（深入）”；
- ✅
std::cerr << "msg" << std::endl;、throw std::runtime_error("...")（若异常处理里用了 cerr） - ❌
fprintf(stderr, "...")、write(STDERR_FILENO, ...)、OutputDebugString（Windows）、__android_log_print（Android） - ⚠️ 第三方库若直接调用 C 标准库或系统调用，不会进你的 log 文件；要彻底捕获，得用
dup2(STDERR_FILENO, ...)（Linux/macOS）或SetStdHandle(STD_ERROR_HANDLE, ...)（Windows），但这属于进程级重定向，和rdbuf()完全无关
多线程下 std::cerr 重定向的隐藏风险
std::cerr 是全局对象，rdbuf() 切换不是原子操作——两个线程同时调用 std::cerr.rdbuf(...) 或一边切换一边输出，结果未定义。
- 不要在多线程环境中动态切换
std::cerr.rdbuf()；若需线程隔离日志，改用线程本地std::ostringstream+ 统一落盘，或接入 spdlog / glog 等成熟日志库 - 即使只做一次初始化（如
main()中），也要确保没有其他线程在初始化完成前就访问std::cerr（尤其注意全局对象构造函数里的输出） - 自定义
std::streambuf子类时，overflow()和sputn()必须线程安全（加锁或无共享状态），glibc 和 MSVC 都对此有明确要求
真正难的不是写出那三行代码，而是想清楚：这个重定向要持续多久、由谁负责生命周期、有没有其他模块在背后偷偷往 stderr 写东西——这些没理清，再“正确”的代码也只跑得了一半。
