为何set /P读取标准输入时，管道与重定向行为存在差异？

这个问题的核心原因在于Windows命令提示符（cmd.exe）处理管道和文件重定向的机制差异，以及set /P命令的输入读取逻辑：

1. 管道的输入处理机制 #

当你使用管道（|）时，cmd会创建两个独立的cmd进程：

• 左侧进程执行type f1，将文件内容输出到管道的写端。
• 右侧进程执行括号内的命令块，从管道的读端获取输入。

关键差异点：右侧的cmd进程会一次性将管道中的所有输入读取到内部缓冲区，然后再开始执行命令块中的命令。当第一个set /P line1=读取缓冲区中的第一行后，剩余的缓冲区内容不会被后续的set /P命令读取——cmd没有设计将缓冲区剩余内容传递给下一个set /P的逻辑，因此第二个set /P line2=会遇到EOF（文件结束符），而set /P在遇到EOF时不会修改变量的值（保持初始的空值）。

2. 文件重定向的输入处理机制 #

当使用重定向（<）时，cmd会直接打开目标文件，并保持文件句柄打开直到整个命令块执行完毕。每个set /P命令执行时，都会从打开的文件中逐行读取下一行内容：

• 第一个set /P line1=读取文件的第一行。
• 第二个set /P line2=继续读取文件的第二行，直到文件结束。

这种逐行按需读取的方式，让每个set /P都能获取到对应的输入行。

验证你的例子 #

再看你的测试命令：

• 管道场景：type f1 | (set line1=&set line2=&set /P line1=&set /P line2=&set line)
  右侧进程先把type f1的两行输出全部读入缓冲区，set /P line1取走第一行后，剩余的第二行无法被set /P line2获取，因此line2保持为空。
• 重定向场景：(set line1=&set line2=&set /P line1=&set /P line2=&set line)<f1
cmd打开f1后，set /P line1读第一行，set /P line2读第二行，因此两个变量都被正确赋值。

内容的提问来源于stack exchange，提问作者bchab