我见过stdout并stderr以各种不同的方式使用过 - 据我所知，它通常用于stdout一般信息和stderr错误等。然而，我也看到stderr用于输出与程序本身相关的信息（但与错误、警告、调试等无关）和用于调试目的（我假设后者使用错误流，以便可以将其过滤掉以帮助调试），以及stdout我认为应该属于的更严重的警告stderr。
所以，我想知道 - 除了一般输出和错误之外，什么时候它被视为理想的使用stdout或stderr与程序输出的内容相关？它是更依赖于程序，还是更通用？
答案1
首先将stdout和分开的原因是为了区分程序数据输出（可能存储在文件中，馈送到管道等）和诊断和绒毛（只有人类操作员真正感兴趣）stderr在终端）。 （对于输入没有自动执行相同操作的方法，但是您可以通过打开并读取控制终端设备而不是 来实现这一点，但会遇到一些麻烦stdin。）因此，如果您可以选择在stdout或上写入内容stderr，则最好的启发式方法可能是“使用我的输出的另一个程序会对这些数据感兴趣吗？”然而，这可能取决于程序和应用程序，因此不存在单一的压倒一切的规则。 （这就是为什么有覆盖选项，例如2>&1中的等等bash。）
答案2
这取决于！一个相关因素是stderr默认情况下是不缓冲的，因为当出现故障时，人们不希望将错误消息释放到缓冲中，而stdout默认情况下是行（终端）或块（否则）缓冲的。尽管失败可能会导致行或块数据的丢失，但这种方法更有效。另一个是程序输出的内容；如果某些东西正在发出特定的格式，例如 CSV 或 JSON，则将错误消息混合到其中可能会损坏它（或者需要以特定格式进行编码，然后如果以该格式对其进行编码时出现错误，会发生什么情况 abort！ abort！ abort！ ），而在其他情况下（交互式菜单类型系统？）将错误消息与其他输出混合可能并不那么重要。
答案3
始终认为有人会在某个时刻将您的程序放入管道中：
$ inputProducer | yourProgram | outputConsumer
在考虑是否将某些内容定向到stderr或 时stdout，重要的是该内容是否与（通用）相关outputConsumer，或者是否只会使其生活变得更加困难。
- 相关的：
stdout - 不相关：
stderr
（请注意，许多错误报告会转到stdout而不是stderr因为人们忘记将其重定向到stderr，即使这本来是更好的选择。）