cerr重定向本质是替换其关联的streambuf，将默认stderr缓冲区换为文件缓冲区；需确保ofstream对象生命周期覆盖全部使用期，否则易致崩溃或日志丢失。
cerr 重定向的本质是替换其关联的 streambuf
控制台错误流 cerr 默认绑定到 stderr 对应的缓冲区，重定向不是改“输出目标”，而是用 rdbuf() 把它底层的 streambuf* 换成一个文件缓冲区。一旦替换，所有通过 cerr 写入的内容都会进文件——包括第三方库（如 Boost、Eigen）中直接写 <code>cerr 的日志。
关键点：必须用 std::ofstream 的 rdbuf()，不能直接传文件名；且 ofstream 必须保持存活，否则缓冲区析构会导致 cerr 指向已释放内存，后续写入触发未定义行为（常见表现是程序崩溃或静默丢日志）。
-
ofstream对象声明必须在cerr.rdbuf(...)之前，且作用域要覆盖所有需要重定向的执行路径 - 重定向后
cerr不再自动 flush 到终端，但依然默认为 unbuffered（实际由新streambuf行为决定），若需立即落盘，得手动cerr 或设置 <code>cerr.setf(ios::unitbuf) - Windows 下路径含中文或空格时，用
u8"路径"或 UTF-8 字符串构造ofstream，避免因 locale 导致打开失败
最简安全重定向写法（C++11 起）
以下代码在 main 开头即可生效，无需 RAII 封装也能保证基本安全：
std::ofstream log_file("error.log", std::ios::out | std::ios::app);
if (log_file.is_open()) {
std::streambuf* old_cerr_buf = std::cerr.rdbuf(log_file.rdbuf());
// 后续所有 cerr 输出都进 error.log
// 注意：log_file 对象不能在此作用域结束前销毁
}⚠️ 容易踩的坑：log_file 若是局部变量且所在函数返回，cerr 就会指向已析构的缓冲区。生产环境建议把 ofstream 声明为全局或静态变量，或者用 RAII 类管理生命周期。
立即学习“C++免费学习笔记（深入）”；
恢复原始 stderr 输出（调试/切换日志时必需）
重定向不是单向操作，随时可用原 streambuf* 恢复：
std::streambuf* old_cerr_buf = nullptr;
{
std::ofstream log_file("error.log");
old_cerr_buf = std::cerr.rdbuf(log_file.rdbuf());
}
// 此时 old_cerr_buf 已失效 —— 错！
// 正确做法：保存前先获取原始 buf
std::streambuf* original_cerr_buf = std::cerr.rdbuf();
std::ofstream log_file("error.log");
std::cerr.rdbuf(log_file.rdbuf());
// ... 使用一段时间后
std::cerr.rdbuf(original_cerr_buf); // 恢复终端输出注意：original_cerr_buf 是 stderr 对应的系统级缓冲区指针，不能 delete，也不能跨线程共享。多线程中若需动态切换，每个线程应独立保存/恢复自己的 cerr.rdbuf()。
重定向后 cerr 的行为变化与兼容性
替换 rdbuf 后，cerr 失去“无缓冲”特性（文件流默认全缓冲），可能导致错误日志延迟写入。尤其在程序异常退出前，最后一段日志可能丢失。
- 解决办法：调用
cerr 启用逐行缓冲，或每次写完加 <code> - 第三方库若检查
cerr.tie()或cerr.good()，行为不变；但若内部调用write(2, ...)直写stderr文件描述符，则不受影响——这类输出仍走终端 - C++20 起可考虑用
std::osyncstream包裹cerr实现线程安全日志，但它不改变rdbuf，仅解决并发写问题
真正麻烦的是信号处理函数（如 SIGSEGV handler）里调用 cerr：此时 ofstream 析构或锁竞争可能引发二次崩溃。这种场景应避免在 signal handler 中使用任何流对象，改用 write(2, ...) 直写 STDERR_FILENO。
