当 process.stdin.isTTY 返回 false（或者在早期 Node.js 版本中为 undefined）时，核心本质是相同的：操作系统没有为这个进程分配一个交互式的虚拟终端设备作为输入源。

在实际开发、部署和自动化运维中，以下 5 种具体情况会导致 isTTY 为 false：

1. 管道重定向（Pipe）

这是最常见的情况。当你使用 Linux/Unix 管道（|）将前一个命令的输出作为 Node.js 程序的输入时，输入流直接变成了前一个程序的数据管道，而不是你的键盘。

# 此时在 node 脚本中，process.stdin.isTTY 为 false
cat data.txt | node app.js

# 或者将 echo 的输出灌给 node
echo "hello" | node app.js

2. 文件输入重定向（Input Redirection）

使用操作系统的重定向符号 <，直接将一个文件的内容“喂”给 Node.js 进程。此时输入源变成了文件流。

# 标准输入直接绑定到了 config.json 文件
node app.js < config.json

3. 在 CI/CD 自动化流水线中运行

在诸如 GitHub Actions、GitLab CI、Jenkins、CircleCI 等自动化构建环境中，为了防止脚本卡死，系统通常不会分配交互式终端（PTY）。

• 如果你在 GitHub Actions 的 run 步骤里执行 node app.js，isTTY 必然是 false。

• 坑： 如果你的脚本内部使用了 inquirer 或 prompts 等依赖 TTY 的交互式输入库，在 CI 环境中运行会直接崩溃或跳过。

4. 作为后台服务/守护进程运行（Daemon）

当 Node.js 作为后台服务运行时，它脱离了任何前台终端控制台：

• 使用 Docker 运行时（未指定 -it 参数）：例如执行 docker run my-node-app，没有开启交互和伪终端分配，isTTY 为 false。

• 使用进程管理器 PM2：PM2 在后台管理应用生命周期，它启动的 Node.js 进程默认不会连接到交互式终端。

• 作为 Linux systemd 服务 或 Windows Service 运行。

5. 在子进程（Child Process）中被调用且未继承标准输入

如果在父级 Node.js 程序中通过 child_process 模块启动了一个子进程，并且没有明确让子进程“继承”父进程的终端，那么子进程的 isTTY 就是 false。

const { spawn } = require('child_process');

// 错误写法（默认）：子进程创建了独立的管道，isTTY 为 false
spawn('node', ['sub_script.js']);

💡 最佳实践：如何优雅应对 false？

如果你的 CLI 工具既支持交互，又支持自动化脚本，请务必利用这个特性做好分流处理：

if (process.stdin.isTTY) {
  // 1. 活人正在用键盘交互
  showInteractiveMenu(); 
} else {
  // 2. 管道或自动化脚本灌入的数据，必须通过流来接收
  let buffer = '';
  process.stdin.on('data', chunk => buffer += chunk);
  process.stdin.on('end', () => {
    if (!buffer.trim()) {
      console.error('错误：未检测到任何输入数据或管道数据。');
      process.exit(1);
    }
    parseData(buffer);
  });
}