仅重定向子进程stderr而忽略stdout是否存在安全风险？

针对你的两个问题，我结合Windows进程模型和System.Diagnostics.Process的行为来逐一解释：

问题1：子进程的stdout输出去向何处？会不会导致阻塞？ #

首先，当你设置RedirectStandardOutput = false时，子进程会继承父进程的标准输出句柄——这也是你查看源码时发现STARTUPINFO的hStdOutput被设为stdout句柄的原因。至于父进程控制台看不到输出，核心原因取决于父进程自身的类型：

• 如果你的父进程是GUI应用（比如WinForms/WPF）：这类程序默认没有关联控制台窗口，它的stdout句柄实际上指向了系统的「空设备（NUL）」。子进程继承这个句柄后，所有输出到stdout的内容都会被系统直接丢弃，自然不会在父进程控制台（甚至父进程根本没有控制台）显示。
• 如果你的父进程是控制台应用但仍看不到输出：那大概率父进程自身的stdout已经被重定向到了其他地方（比如文件、管道），子进程的输出会跟着流向那个目的地，而非当前控制台窗口。

关于缓冲区阻塞的问题：

• 如果子进程的stdout指向NUL设备：写入NUL的操作是立即返回的，系统不会缓存这些数据，完全不用担心缓冲区被填满导致子进程阻塞的情况，子进程可以持续输出而不受影响。
• 如果子进程的stdout指向其他目的地（比如父进程重定向过的文件/管道）：若读取端未及时处理数据，子进程的stdout缓冲区（默认通常为4KB或8KB）被填满后，后续的写入操作会被阻塞，直到缓冲区有空闲空间。但结合你的描述（父进程控制台无输出），这种情况概率极低，更可能是前一种场景。

问题2：仅重定向stderr是否安全？ #

仅重定向stderr是安全的，前提是你要保证父进程及时读取子进程的stderr输出（就像你当前实现的那样）。

你之前遇到的「重定向stdout并丢弃数据导致父进程管道写入性能暴跌」的问题，根源很清晰：当你重定向了stdout但不读取时，子进程向stdout输出的内容会填满自身的输出缓冲区，导致子进程卡在写入操作上无法继续执行。此时子进程无法及时处理来自父进程命名管道的请求，父进程向管道写入数据时，管道缓冲区很快就会被填满，父进程的写入操作会被阻塞，因此耗时从<1ms暴涨到>4s。

而只重定向stderr的场景下：

• 只要父进程持续读取stderr的输出，子进程的stderr缓冲区就不会被填满，子进程可以正常运行。
• 子进程的stdout要么被丢到NUL（无阻塞风险），要么流向不会阻碍它执行的目的地，不会影响子进程的运行效率，自然也不会拖慢父进程的管道写入操作。

另外补充一个小建议：如果你实在担心stdout的潜在问题（比如不确定子进程的stdout去向），可以显式将子进程的stdout重定向到NUL设备，彻底规避阻塞风险，而且不会影响性能。具体做法可以设置ProcessStartInfo.RedirectStandardOutput = true，然后在子进程启动后开启一个线程持续读取StandardOutput并丢弃（比如直接读空），这种方式用Process类实现起来很便捷。

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