C++如何获取程序标准错误流是否已被重定向至外部文件或设备

最可靠方式是POSIX调用isatty(STDERR_FILENO)判断是否连终端，Windows用GetFileType(GetStdHandle(STD_ERROR_HANDLE))检查句柄类型；std::cerr.rdbuf()不可靠，argv或环境变量推断完全无效。

如何判断 stderr 是否被重定向（Linux/macOS）

在 Unix-like 系统上，stderr 对应文件描述符 2，是否重定向取决于它是否指向终端设备。最可靠的方式是调用 isatty(2) 判断：isatty(2) 返回 0 表示不连终端，大概率已被重定向（到文件、管道或网络 socket）；返回非零表示仍连终端。

注意：isatty 是 C 函数，C++ 中需包含 <unistd.h>（POSIX）并传入 STDERR_FILENO：

#include <unistd.h>
#include <iostream>

if (!isatty(STDERR_FILENO)) {
    std::cerr << "stderr is redirected or not a TTYn";
}

常见误判场景：即使重定向到伪终端（如 script 命令）、某些容器环境或 systemd-journald，isatty 也可能返回真 —— 它只反映内核对 fd 的 tty 关联状态，不保证“用户可见”。

Windows 下如何检测 stderr 是否重定向

Windows 没有等价的 isatty 语义，需用 GetFileType + GetStdHandle 组合判断。关键点：若 GetFileType 返回 FILE_TYPE_DISK 或 FILE_TYPE_PIPE，说明已重定向；若为 FILE_TYPE_CHAR 且关联控制台，则大概率未重定向。

立即学习“C++免费学习笔记（深入）”；

实操步骤：

• 调用 GetStdHandle(STD_ERROR_HANDLE) 获取句柄
• 检查句柄是否有效（非 INVALID_HANDLE_VALUE 且不为 NULL）
• 对句柄调用 GetFileType()，结果为 FILE_TYPE_DISK 或 FILE_TYPE_PIPE → 已重定向
• 若为 FILE_TYPE_CHAR，再调用 GetConsoleMode() 看是否能获取控制台模式 —— 若失败，可能已被重定向或无控制台

注意：freopen 或命令行重定向（2>file.log）都会让 GetFileType 返回 FILE_TYPE_DISK；但以 CREATE_NO_WINDOW 启动的进程可能根本无 stderr 句柄，需先判空。

std::cerr.rdbuf() 能不能用来检测重定向？

不能直接依赖。C++ 标准流的 rdbuf() 返回的是当前绑定的 streambuf*，但它不暴露底层 OS 句柄信息。例如：freopen("err.log", "w", stderr) 后，std::cerr.rdbuf() 仍是 stdout 关联的缓冲区（取决于实现），不会自动更新；而 std::cerr.tie(nullptr) 或自定义 streambuf 更会让判断完全失效。

更糟的是：rdbuf()->fd() 这类非标准扩展（如 libstdc++ 的 __gnu_cxx::stdio_filebuf::fd()）不可移植，MSVC 不提供，Clang/libc++ 也不保证存在。

结论：绕过 C++ 流抽象，直接查 OS 文件描述符/句柄才是唯一可信赖路径。

为什么不能只看 argv[0] 或环境变量？

有人试图通过解析启动命令（如检查 argv 是否含 "2>"）或读取 TERM 环境变量来推断，这完全不可靠。Shell 重定向由 shell 解析后直接操作 fd，进程启动后 argv 里根本不会出现重定向符号；TERM 只表示终端类型，与 stderr 是否重定向无关 —— 即使 TERM=xterm-256color，stderr 也可能早已被 2>/dev/null 关闭。

真正起作用的只有运行时 fd/句柄的状态。任何基于字符串匹配或环境推测的方法，在 systemd、容器、CI 环境中极易失效。

跨平台判断逻辑必须分支处理：POSIX 用 isatty(STDERR_FILENO)，Windows 用 GetFileType(GetStdHandle(STD_ERROR_HANDLE))，二者都不能省略错误检查（比如句柄被关闭、权限不足），否则会触发未定义行为。