最可靠方式是调用isatty(STDIN_FILENO)或_windows版_isatty(_fileno(stdin))：返回0表示已重定向（管道/文件），非0表示连接终端；该方法检查底层文件描述符，不受C++流状态影响，跨平台可移植且无运行时开销。
如何判断 stdin 是否被重定向（而非终端输入）
直接看 isatty(STDIN_FILENO) 返回值——返回 0 表示已重定向（如管道、文件输入），非零表示连接到终端。这是最轻量、最可靠的方式，不依赖 C++ 流状态，也不受缓冲或 cin 内部标志干扰。
注意：必须包含 <unistd.h>（POSIX 系统）或 <>io.h>（Windows）并用 _isatty(_fileno(stdin))；cin.tie() 或 cin.good() 完全无法反映重定向状态。
-
isatty检查的是底层文件描述符，不是 C++ 流对象，所以即使cin已被修改（如cin.sync_with_stdio(false)），结果仍准确 - 在 Windows 上务必用
_isatty+_fileno，直接传stdin给isatty会编译失败或行为未定义 - 如果程序启动时通过
./a.out < input.txt或echo "x" | ./a.out调用，isatty返回0
cin 的 rdbuf() 能否用于检测重定向
不能可靠使用。虽然 cin.rdbuf() 返回的 streambuf* 类型可能随输入源变化，但标准库未规定其具体实现差异——例如 libstdc++ 和 libc++ 对文件重定向和管道的 streambuf 子类可能完全相同，无法区分。
更关键的是：cin.rdbuf() 在重定向前后都可能返回 __gnu_cxx::stdio_sync_filebuf<char>* 这类类型，无实际判别价值。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要尝试用
dynamic_cast或typeid检查cin.rdbuf()类型来判断重定向 - 即便某次测试中观察到类型不同，也属于实现细节，跨平台/跨标准库版本不可移植
- 该方法在交互式调试时还可能因 IDE 的伪终端封装（如 VS Code 的集成终端）产生误判
为什么 cin.fail() 或 cin.eof() 不适合作为重定向检测依据
因为这两个状态只反映**已发生的读取结果**，而非当前输入源性质。刚启动程序时，无论是否重定向，cin.fail() 和 cin.eof() 都是 false；只有执行过读取操作并失败/到达末尾后才会改变。
- 用
cin.peek() == EOF判断？错——重定向到空文件时立即返回EOF，但重定向到非空文件或管道时不会 - 用
cin >> x后检查fail()？这会消耗第一个输入字符，破坏后续逻辑，且无法区分“没输”和“输错格式” - 试图用
fstat(STDIN_FILENO, &sb)查sb.st_mode？Linux 下对管道/proc/self/fd/0 可能返回S_IFIFO或S_IFREG，但 macOS 和某些容器环境行为不一致，实用性低
跨平台可移植的最小检测封装
把平台差异收到底层，暴露统一接口：
#ifdef _WIN32 #include <io.h> #include <fcntl.h> #define IS_STDIN_TTY() (_isatty(_fileno(stdin))) #else #include <unistd.h> #define IS_STDIN_TTY() (isatty(STDIN_FILENO)) #endif
调用时直接写 if (IS_STDIN_TTY()) { /* 交互模式 */ } else { /* 批处理模式 */ } 即可。这个宏在所有主流编译器（MSVC/GCC/Clang）和操作系统（Linux/macOS/Windows）上都有效，且无运行时开销。
真正容易被忽略的是：某些 CI 环境（如 GitHub Actions 的 runner）或容器内，即使没显式重定向，stdin 也可能被设为 /dev/null 或关闭——此时 isatty 返回 0，且后续读取会立刻 EOF，需额外用 read(STDIN_FILENO, &dummy, 1) == 0 做二次确认是否真为空流。
