cerr重定向的本质是替换其关联的streambuf，即通过cerr.rdbuf()将默认stderr缓冲区指向文件流（如ofstream）的缓冲区，从而使所有cerr输出（含第三方库调用）写入文件。
cerr 重定向的本质是替换其关联的 streambuf
直接操作 cerr.rdbuf() 是唯一标准、跨平台且不依赖宏或运行时开关的方式。它不修改 cerr 对象本身，而是将其底层缓冲区（streambuf*）指向另一个具备文件写入能力的缓冲区，比如 ofstream 内部的 rdbuf()。这意味着所有对 cerr 的输出（包括第三方库中未加判断的 cerr ）都会自动流入目标文件。
关键点在于：必须保持被替换的 streambuf* 生命周期长于 cerr 的使用期，否则会触发未定义行为——这是最常踩的坑。
用 ofstream + rdbuf() 完成重定向的三步实操
以下是最小可行代码，适用于 C++11 及以上：
std::ofstream log_file("error.log");
std::streambuf* old_cerr_buf = std::cerr.rdbuf(log_file.rdbuf());
// 后续所有 cerr 输出都写入 error.log
std::cerr
-
log_file必须声明在作用域开头，不能是临时对象（如std::ofstream("error.log").rdbuf()） - 保存原始
rdbuf()指针（old_cerr_buf）是恢复的前提；丢失它就无法还原 - 调用
cerr.rdbuf(...)返回的是**之前的缓冲区指针**，不是新设置的那个 - 如果不需要恢复，可省略保存与还原步骤，但
log_file仍需在程序退出前保持有效
重定向后 cerr 不再输出到控制台，但 cout/clog 不受影响
cerr、cout、clog 三者各自持有独立的 streambuf*，互不干扰。重定向 cerr 不会改变 cout 的行为，也不会影响 std::ios_base::sync_with_stdio() 的设置状态。
常见误判场景：
- 误以为重定向后
cerr和cout会“合并”到同一文件 → 实际上它们完全独立 - 在多线程环境中未加锁就并发写
cerr→ 即使重定向到文件，cerr本身不保证线程安全，需自行同步 - 重定向后发现日志缺失 → 很可能是程序异常退出未执行
log_file.close()或未 flush，建议在重定向后显式调用std::cerr.flush()
Windows 下注意文件路径和权限，Linux 下注意 stderr 的 dup 行为
虽然 rdbuf() 方式本身跨平台，但底层文件操作受系统约束：
- 路径含中文或空格时，Windows 上需确保控制台编码与文件保存编码一致（推荐 UTF-8 with BOM 或使用
std::filesystem::path构造） - Linux 下若程序由 shell 启动并重定向了
stderr（如./a.out 2>err.log），再在代码中调用cerr.rdbuf()仍会生效——C++ 层的重定向优先级高于 shell 层，但两者叠加可能导致日志重复或错乱 - 某些嵌入式或受限环境（如 iOS App Extension）禁止写本地文件，此时
ofstream构造失败，log_file.is_open()将返回false，必须检查
真正难处理的不是重定向动作本身，而是生命周期管理与错误回退：一旦 ofstream 构造失败或中途关闭，cerr.rdbuf() 就指向了无效内存。生产环境建议封装成 RAII 类，或至少用 std::unique_ptr<:ofstream></:ofstream> 管理文件句柄。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
