为什么使用System.out.println（）这么糟糕？[关闭]

当然，对错误消息或警告使用日志记录框架非常有用。但是有时候如果我想在短时间内尝试一些新的东西，我会使用System.out.println（）。

使用System.out.println（）进行快速测试真的很糟糕吗？

正如评论中所揭示的，真正要问的问题是，为什么静态代码分析工具会标记System.out.println的使用？

原因是在生产环境中通常不适合向stdout发送消息。如果要对库进行编码，则库应将信息返回给其调用方，而不是打印到stdout。如果您正在编写GUI应用程序，则应将信息显示给用户，而不是显示stdout指向的位置（可能不指向任何地方）。如果要对服务器（或在服务器端容器中运行的服务器）进行编码，则应使用框架提供的任何日志记录工具。依此类推。

但是，如果您使用println进行调试或开发，或者您正在编写程序并读取stdin并将其写入stdout，则println非常好。在这种情况下，它没有错。

所有stdout被缓冲，因此它是可能的，你的程序会崩溃以后你叫println()，但之前它到达屏幕。

话虽如此，这种情况真的不太可能。继续使用并使用它，但只需将较小的限制放在脑海中即可。

System.out只是一个包裹BufferedOutputStream。这可能与您将使用的任何日志记录框架相似，这些框架仅以日志输出的配置和目标形式提供更多功能。

如果您使用的是非平凡的程序，那很不好

• 将System.out用作拐杖，而不是自动进行单元测试（JUnit）
• 花大量时间创建和删除System.out语句或对其进行注释/取消注释

关于使用System.out，即使在一次性代码中也有一些注意事项。

一个主要问题是它通常很慢。例如，如果您想大致了解某些代码的速度（请注意，微基准测试很困难），则在System.out.println()任何位置添加单个代码确实会弄乱您的时间（因为它正在同步并且经常等待实际输出到返回之前对用户可见）。

除此之外，我不会在一次性代码中对此太担心。如果您打算提交它（作为生产代码或作为测试代码），则应删除它，并用适当的日志记录调用替换它（是的，即使在测试代​​码中）。

通常，答案是“取决于”。如果您的应用程序已经有一个日志记录框架，那么您也可以使用它。它不能少有能力println()，你可以从它提供协议栈等特点痕迹，额外的上下文，更好地格式化，等受益。日志记录框架还具有提供更好的错误恢复的独特可能性，即使在发生灾难性故障的情况下，也可以确保成功写入日志。

因此，问题就变成了何时首先添加日志记录系统。这是一个判断电话：您不想过早添加它，只是发现您确实不需要它。您也不想添加得太晚，并且要从临时解决方案转换过多的工作。

如果发现您使用进行了大量日志记录println()，则您的代码库正在尝试告诉您它正在经历越来越大的痛苦。到那时，值得投资适当的日志记录。

我经常遇到这样的问题，即System.out.print使用“系统默认”代码页，在Linux下通常为UTF-8，而在Windows下却有些MS的东西。

根据程序的运行位置，这可能会导致unicode字符正确地显示在屏幕上。

因此，相对于System.out，我更喜欢自定义PrintWriter

一点也不坏。这个概念可能源于以下事实：它非常简单，而不像在应用程序中使用专用日志记录框架那样复杂。

但是，这并不是说这是一种无效的方法。在使用一些黑巫术伏都教编程技巧之后，我已经多次使用它来检查应用程序流程。

使用它没有任何问题，它可以帮助您弄清楚“到底发生了什么”。

但是，如果您的同龄人/其他开发人员/工具在嘲笑您，您可以始终使用Logger或开始Junit测试！

正如我所看到的那样，时空System.out.println的最大问题是它是“不良习惯气味（tm）”。如果您发现自己正在执行此操作，则可以通过使用自己喜欢的调试器更加自在来提高效率。

同样，使用调试器，您肯定知道断点不会插入您的生产代码中，而System.out.println可能会断点。

附带说明一下，如果您实际上只是在进行快速测试并且坚持不使用调试器，那么我认为System.out.println比使用日志记录框架要好，因为如果您不小心留下了log.debug语句，完成后，很难根除。

围绕回声内部状态的内容来构建整个测试策略并不是最明智的举动，但是对于开发中的快速而肮脏的代码测试，只要您记得将其删除，这里的println就不会受到伤害！

建议不要删除它们，而忘记删除它们的危险。