可以从中恢复的警告。错误你不能。这是我的启发，其他人可能有其他想法。

例如，假设您在应用程序中输入/导入名称“Angela Müller”（注意u上的元音变音）。您的代码/数据库可能仅为英文（尽管它可能不应该在这个时代），因此可能会警告所有“不寻常”字符都已转换为普通英文字符。

与之形成对比的是，尝试将信息写入数据库，并连续60秒返回网络关闭消息。这与其说是警告，不如说是错误。

下面是“伐木工人”的清单。

Apache日志4j:§1，§2

致命：[v1.2:..]非常严重的错误事件，可能会导致应用程序中止。[v2.0:..]严重错误，将阻止应用程序继续运行。错误：[v1.2:..]可能仍然允许应用程序继续运行的错误事件。[v2.0:..]应用程序中的错误，可能可以恢复。警告：[v1.2:..]潜在的有害情况。[v2.0:..]事件可能导致错误。信息：[v1.2:..]在粗粒度级别突出显示应用程序进度的信息性消息。[v2.0:..]事件，仅供参考。调试：[v1.2:..]对调试应用程序最有用的细粒度信息事件。[v2.0:..]常规调试事件。跟踪：[v1.2:..]比DEBUG更细粒度的信息事件。[v2.0:..]细粒度调试消息，通常捕获通过应用程序的流。

Apache Httpd（和往常一样）喜欢过度使用：§

紧急情况：紧急情况–系统不可用。警觉的：必须立即采取行动[但系统仍然可用]。比容：关键条件[但无需立即采取行动]。套接字：无法获取套接字，正在退出子级错误：错误条件[但不重要]。“脚本头过早结束”警告：警告条件。[接近错误，但不是错误]通知：正常但显著的情况。httpd:捕获SIGBUS，试图在中转储核心信息：信息[和不可旋转]。[“服务器已运行x小时。”]调试：调试级消息[，即为调试而记录的消息）]。“正在打开配置文件…”痕迹1→ 痕迹6：跟踪消息[，即为跟踪而记录的消息]。“代理：FTP：控制连接完成”“proxy:CONNECT:向远程代理发送CONNECT请求”“openssl:握手：启动”“从缓冲SSL旅读取，模式0，17字节”“地图查找失败：map=rewriteitemap key=keyname”缓存查找失败，强制新的映射查找痕迹7→ 痕迹8：跟踪消息，转储大量数据“|0000:02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |”“|0000:02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |”

Apache commons日志记录：§

致命：导致提前终止的严重错误。期望这些在状态控制台上立即可见。错误：其他运行时错误或意外情况。期望这些在状态控制台上立即可见。警告：使用不推荐使用的API、API使用不当、“几乎”错误、其他不希望或意外但不一定“错误”的运行时情况。期望这些在状态控制台上立即可见。信息：有趣的运行时事件（启动/关闭）。期望这些在控制台上立即可见，所以要保守，尽量减少。调试：有关通过系统的流程的详细信息。期望这些仅写入日志。跟踪：更详细的信息。期望这些仅写入日志。

Apache commons记录企业使用的“最佳实践”，根据调试和信息跨越的界限来区分它们。

边界包括：

外部边界-预期异常。外部边界-意外异常。内部边界。重要内部边界。

（有关详细信息，请参阅commons日志记录指南。）

正如其他人所说，错误是问题；警告是潜在的问题。

在开发中，我经常使用警告，在警告中，我可能会放置相当于断言失败，但应用程序可以继续工作；这使我能够发现这个案子是否真的发生过，或者这是我的想象。

但是的，它归结到恢复性和现实性方面。如果你能恢复，那可能是一个警告；如果它导致某个东西实际失败，那就是一个错误。

塔科·扬·奥辛加的回答非常好，而且非常实用。

我同意他的观点，尽管有些不同。

在Python上，只有5个“命名”日志级别，所以我是这样使用它们的：

调试——对故障排除很重要的信息，通常在正常的日常操作中被抑制信息——日常操作，作为程序按设计执行功能的“证明”警告——超出名义但可恢复的情况，*或*遇到可能导致未来问题的事情错误——发生了一些需要程序执行恢复的事情，但恢复成功。不过，程序可能没有处于最初预期的状态，因此程序用户需要进行调整关键——发生了无法挽回的事情，程序可能需要终止，以免每个人都生活在罪恶的状态中

我建议只使用三个级别

致命-这会破坏应用程序。信息-信息调试-不太重要的信息

我完全同意其他人的观点，并认为GrayWizardx说得最好。

我所能补充的是，这些级别通常对应于它们的字典定义，所以这并不难。如果有疑问，请像拼图一样对待它。对于您的特定项目，考虑您可能想要记录的所有内容。

现在，你能找出什么可能是致命的吗？你知道什么是致命的，不是吗？那么，你的清单上哪些项目是致命的。

好的，这是致命的问题，现在让我们看看错误。。。冲洗并重复。

在“致命”以下，或者可能是“错误”以下，我建议信息多总比信息少好，所以错误“向上”。不确定是信息还是警告？然后发出警告。

我确实认为，致命和错误应该是我们所有人都清楚的。其他的可能更模糊，但可以说，把它们弄对并不那么重要。

以下是一些示例：

致命-无法分配内存、数据库等-无法继续。

错误-没有回复消息、事务中止、无法保存文件等。

警告-资源分配达到X%（例如80%）-这表明您可能需要重新调整维度。

信息-用户登录/注销、新事务、文件装箱、新d/b字段或删除的字段。

内部数据结构的调试转储，任何带有文件名和行号的跟踪级别。跟踪-操作成功/失败，已更新d/b。