LOG设置就是日志设置。
通常是系统或者某些软件对已完成的某种处理的记录，以便将来做为参考，它并没有固定的格式，通常是文本文件，可以用记事本打开以查看内容，当然很可能是其它格式，直接打开就是乱码。
大部分的log可以从文件名看出它的作用，比如uninstall.log或是error.log，当然前者通常是软件安装过程中生成的记录，以便将来卸载的时候可以提供给卸载程序使用，后者通常是用来记录一些软件运行中的错误信息等等。
扩展资料
网络设备、系统及服务程序等，在运作时都会产生一个叫log的事件记录；每一行日志都记载着日期、时间、使用者及动作等相关操作的描述。
Windows网络操作系统都设计有各种各样的日志文件，如应用程序日志，安全日志、系统日志、Scheduler服务日志、FTP日志、WWW日志、DNS服务器日志等等，这些根据你的系统开启的服务的不同而有所不同。
我们在系统上进行一些操作时，这些日志文件通常会记录下我们操作的一些相关内容，这些内容对系统安全工作人员相当有用。比如说有人对系统进行了IPC探测，系统就会在安全日志里迅速地记下探测者探测时所用的IP、时间、用户名等，用FTP探测后，就会在FTP日志中记下IP、时间、探测所用的用户名等。
参考资料来源：百度百科-log文件
温馨提示：答案为网友推荐，仅供参考
第1个回答 推荐于2017-09-13
软件中总免不了要使用诸如 Log4net, Log4j, Tracer 等东东来写日志，不管用什么，这些东东大多是大同小异的，一般都提供了这样5个日志级别：
× Debug
× Info
× Warn
× Error
× Fatal
一个等级比一个高，但是在具体开发中，关于应该如何选择适应的等级，却没有找到好的文章进行说明。记录一下自己的一些看法，以便日后使用吧。
这个级别最低的东东，一般的来说，在系统实际运行过程中，一般都是不输出的。
因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出来看看也无妨。
当然，在每一个 Debug 调用之前，一定要加上 If 判断。
这个应该用来反馈系统的当前状态给最终用户的，所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
从某种角度上说，Info 输出的信息可以看作是软件产品的一部分（就像那些交互界面上的文字一样），所以需要谨慎对待，不可随便
警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的状态，他们之间的区别，要区分还真不是那么简单的事情。我大致是这样区分的：
所谓警告，应该是这个时候进行一些修复性的工作，应该还可以把系统恢复到正常状态中来，系统应该可以继续运行下去。
所谓错误，就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。
所谓Fatal，那就是相当严重的了，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话，可以肯定必然会越来越乱。这时候采取的最好的措施不是试图将系统状态恢复到正常，而是尽可能地保留系统有效数据并停止运行。
也就是说，选择 Warn、Error、Fatal 中的具体哪一个，是根据当前的这个问题对以后可能产生的影响而定的，如果对以后基本没什么影响，则警告之，如果肯定是以后要出严重问题的了，则Fatal之，拿不准会怎么样，则 Error 之。
不过在实际使用中，基于上面的这种考虑，也还是有一些具体问题。最常见的就是要在最终产品中将输出日志打开到那种级别才算好呢？
例如在应用中有一个输出窗口，一些系统状态信息将被输出到这个输出窗口中。因为 Info 的级别是如此之低，所以为了让用户能够看到有效的输出信息，必须将日志级别开放到 Info 级别。但是 Warn 的级别比 Info 要高，所以用户不得不被迫看到一些 Warn 的信息。而我们其实已经假定，Warn 信息其实并不影响系统的正常运行，这一般只代表系统中存在一些还没有被发现或者修改的小 Bug。这些 Warn 信息会让最终用户困惑甚至恐慌，系统发出警告了，该怎么办？
个人观点，Info 的级别应该比 Warn 更高才对，Warn 信息和 Debug 一样，应该在产品测试和调试时使用，而 Info、Erro 以及 Fatal 则在产品发布后需要继续使用。
目前我所采用的解决方法是，对于 Warn、Error、Fatal 都添加一个相应的系统断言，这样，可以保证当发生这种问题时，在调试阶段，可以立即得到提示。在软件发布以后，这些信息也能被记录到日志文件中去。
{{{
log.Warn("message");
System.Diagnostics.Debug.Fail("警告", "message");
}}}
Debug.Fail 将导致编译为 Debug 输出时，会弹出一个消息警告窗口，这可保证在测试、调试阶段不漏过任何一个潜在的错误。而在发布时，Release 编译的输出不会包括 Debug 语句，这就不会打扰最终用户，而错误信息仍然能通过 log 记录到日志中
× Debug
× Info
× Warn
× Error
× Fatal
一个等级比一个高，但是在具体开发中，关于应该如何选择适应的等级，却没有找到好的文章进行说明。记录一下自己的一些看法，以便日后使用吧。
这个级别最低的东东，一般的来说，在系统实际运行过程中，一般都是不输出的。
因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出来看看也无妨。
当然，在每一个 Debug 调用之前，一定要加上 If 判断。
这个应该用来反馈系统的当前状态给最终用户的，所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
从某种角度上说，Info 输出的信息可以看作是软件产品的一部分（就像那些交互界面上的文字一样），所以需要谨慎对待，不可随便
警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的状态，他们之间的区别，要区分还真不是那么简单的事情。我大致是这样区分的：
所谓警告，应该是这个时候进行一些修复性的工作，应该还可以把系统恢复到正常状态中来，系统应该可以继续运行下去。
所谓错误，就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。
所谓Fatal，那就是相当严重的了，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话，可以肯定必然会越来越乱。这时候采取的最好的措施不是试图将系统状态恢复到正常，而是尽可能地保留系统有效数据并停止运行。
也就是说，选择 Warn、Error、Fatal 中的具体哪一个，是根据当前的这个问题对以后可能产生的影响而定的，如果对以后基本没什么影响，则警告之，如果肯定是以后要出严重问题的了，则Fatal之，拿不准会怎么样，则 Error 之。
不过在实际使用中，基于上面的这种考虑，也还是有一些具体问题。最常见的就是要在最终产品中将输出日志打开到那种级别才算好呢？
例如在应用中有一个输出窗口，一些系统状态信息将被输出到这个输出窗口中。因为 Info 的级别是如此之低，所以为了让用户能够看到有效的输出信息，必须将日志级别开放到 Info 级别。但是 Warn 的级别比 Info 要高，所以用户不得不被迫看到一些 Warn 的信息。而我们其实已经假定，Warn 信息其实并不影响系统的正常运行，这一般只代表系统中存在一些还没有被发现或者修改的小 Bug。这些 Warn 信息会让最终用户困惑甚至恐慌，系统发出警告了，该怎么办？
个人观点，Info 的级别应该比 Warn 更高才对，Warn 信息和 Debug 一样，应该在产品测试和调试时使用，而 Info、Erro 以及 Fatal 则在产品发布后需要继续使用。
目前我所采用的解决方法是，对于 Warn、Error、Fatal 都添加一个相应的系统断言，这样，可以保证当发生这种问题时，在调试阶段，可以立即得到提示。在软件发布以后，这些信息也能被记录到日志文件中去。
{{{
log.Warn("message");
System.Diagnostics.Debug.Fail("警告", "message");
}}}
Debug.Fail 将导致编译为 Debug 输出时，会弹出一个消息警告窗口，这可保证在测试、调试阶段不漏过任何一个潜在的错误。而在发布时，Release 编译的输出不会包括 Debug 语句，这就不会打扰最终用户，而错误信息仍然能通过 log 记录到日志中
第2个回答 推荐于2017-10-12
日志。以下内容是复制的
软件中总免不了要使用诸如 Log4net, Log4j, Tracer 等东东来写日志，不管用什么，这些东东大多是大同小异的，一般都提供了这样5个日志级别：
× Debug
× Info
× Warn
× Error
× Fatal
一个等级比一个高，但是在具体开发中，关于应该如何选择适应的等级，却没有找到好的文章进行说明。记录一下自己的一些看法，以便日后使用吧。
=== Debug ===
这个级别最低的东东，一般的来说，在系统实际运行过程中，一般都是不输出的。
因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出来看看也无妨。
当然，在每一个 Debug 调用之前，一定要加上 If 判断。
=== Info ===
这个应该用来反馈系统的当前状态给最终用户的，所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
从某种角度上说，Info 输出的信息可以看作是软件产品的一部分（就像那些交互界面上的文字一样），所以需要谨慎对待，不可随便。
=== Warn、Error、Fatal ===
警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的状态，他们之间的区别，要区分还真不是那么简单的事情。我大致是这样区分的：
所谓警告，应该是这个时候进行一些修复性的工作，应该还可以把系统恢复到正常状态中来，系统应该可以继续运行下去。
所谓错误，就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。
所谓Fatal，那就是相当严重的了，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话，可以肯定必然会越来越乱。这时候采取的最好的措施不是试图将系统状态恢复到正常，而是尽可能地保留系统有效数据并停止运行。
也就是说，选择 Warn、Error、Fatal 中的具体哪一个，是根据当前的这个问题对以后可能产生的影响而定的，如果对以后基本没什么影响，则警告之，如果肯定是以后要出严重问题的了，则Fatal之，拿不准会怎么样，则 Error 之。
=== 一些疑惑 ===
不过在实际使用中，基于上面的这种考虑，也还是有一些具体问题。最常见的就是要在最终产品中将输出日志打开到那种级别才算好呢？
例如在应用中有一个输出窗口，一些系统状态信息将被输出到这个输出窗口中。因为 Info 的级别是如此之低，所以为了让用户能够看到有效的输出信息，必须将日志级别开放到 Info 级别。但是 Warn 的级别比 Info 要高，所以用户不得不被迫看到一些 Warn 的信息。而我们其实已经假定，Warn 信息其实并不影响系统的正常运行，这一般只代表系统中存在一些还没有被发现或者修改的小 Bug。这些 Warn 信息会让最终用户困惑甚至恐慌，系统发出警告了，该怎么办？
个人观点，Info 的级别应该比 Warn 更高才对，Warn 信息和 Debug 一样，应该在产品测试和调试时使用，而 Info、Erro 以及 Fatal 则在产品发布后需要继续使用。
目前我所采用的解决方法是，对于 Warn、Error、Fatal 都添加一个相应的系统断言，这样，可以保证当发生这种问题时，在调试阶段，可以立即得到提示。在软件发布以后，这些信息也能被记录到日志文件中去。
{{{
log.Warn("message");
System.Diagnostics.Debug.Fail("警告", "message");
}}}
Debug.Fail 将导致编译为 Debug 输出时，会弹出一个消息警告窗口，这可保证在测试、调试阶段不漏过任何一个潜在的错误。而在发布时，Release 编译的输出不会包括 Debug 语句，这就不会打扰最终用户，而错误信息仍然能通过 log 记录到日志中。追问
软件中总免不了要使用诸如 Log4net, Log4j, Tracer 等东东来写日志，不管用什么，这些东东大多是大同小异的，一般都提供了这样5个日志级别：
× Debug
× Info
× Warn
× Error
× Fatal
一个等级比一个高，但是在具体开发中，关于应该如何选择适应的等级，却没有找到好的文章进行说明。记录一下自己的一些看法，以便日后使用吧。
=== Debug ===
这个级别最低的东东，一般的来说，在系统实际运行过程中，一般都是不输出的。
因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出来看看也无妨。
当然，在每一个 Debug 调用之前，一定要加上 If 判断。
=== Info ===
这个应该用来反馈系统的当前状态给最终用户的，所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
从某种角度上说，Info 输出的信息可以看作是软件产品的一部分（就像那些交互界面上的文字一样），所以需要谨慎对待，不可随便。
=== Warn、Error、Fatal ===
警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的状态，他们之间的区别，要区分还真不是那么简单的事情。我大致是这样区分的：
所谓警告，应该是这个时候进行一些修复性的工作，应该还可以把系统恢复到正常状态中来，系统应该可以继续运行下去。
所谓错误，就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。
所谓Fatal，那就是相当严重的了，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话，可以肯定必然会越来越乱。这时候采取的最好的措施不是试图将系统状态恢复到正常，而是尽可能地保留系统有效数据并停止运行。
也就是说，选择 Warn、Error、Fatal 中的具体哪一个，是根据当前的这个问题对以后可能产生的影响而定的，如果对以后基本没什么影响，则警告之，如果肯定是以后要出严重问题的了，则Fatal之，拿不准会怎么样，则 Error 之。
=== 一些疑惑 ===
不过在实际使用中，基于上面的这种考虑，也还是有一些具体问题。最常见的就是要在最终产品中将输出日志打开到那种级别才算好呢？
例如在应用中有一个输出窗口，一些系统状态信息将被输出到这个输出窗口中。因为 Info 的级别是如此之低，所以为了让用户能够看到有效的输出信息，必须将日志级别开放到 Info 级别。但是 Warn 的级别比 Info 要高，所以用户不得不被迫看到一些 Warn 的信息。而我们其实已经假定，Warn 信息其实并不影响系统的正常运行，这一般只代表系统中存在一些还没有被发现或者修改的小 Bug。这些 Warn 信息会让最终用户困惑甚至恐慌，系统发出警告了，该怎么办？
个人观点，Info 的级别应该比 Warn 更高才对，Warn 信息和 Debug 一样，应该在产品测试和调试时使用，而 Info、Erro 以及 Fatal 则在产品发布后需要继续使用。
目前我所采用的解决方法是，对于 Warn、Error、Fatal 都添加一个相应的系统断言，这样，可以保证当发生这种问题时，在调试阶段，可以立即得到提示。在软件发布以后，这些信息也能被记录到日志文件中去。
{{{
log.Warn("message");
System.Diagnostics.Debug.Fail("警告", "message");
}}}
Debug.Fail 将导致编译为 Debug 输出时，会弹出一个消息警告窗口，这可保证在测试、调试阶段不漏过任何一个潜在的错误。而在发布时，Release 编译的输出不会包括 Debug 语句，这就不会打扰最终用户，而错误信息仍然能通过 log 记录到日志中。追问
什么标准,详细点?
追答日志。软件中总免不了要使用诸如 Log4net, Log4j, Tracer 等东东来写日志，不管用什么，这些东东大多是大同小异的，一般都提供了这样5个日志级别：
× Debug
× Info
× Warn
× Error
× Fatal
一个等级比一个高，但是在具体开发中，关于应该如何选择适应的等级，却没有找到好的文章进行说明。记录一下自己的一些看法，以便日后使用吧。
=== Debug ===
这个级别最低的东东，一般的来说，在系统实际运行过程中，一般都是不输出的。
因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出来看看也无妨。
当然，在每一个 Debug 调用之前，一定要加上 If 判断。
=== Info ===
这个应该用来反馈系统的当前状态给最终用户的，所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
从某种角度上说，Info 输出的信息可以看作是软件产品的一部分（就像那些交互界面上的文字一样），所以需要谨慎对待，不可随便。
=== Warn、Error、Fatal ===
警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的运行。
另，其实我本来写的是手机标志。啊哈哈哈。
第3个回答 2015-06-19
软件中总免不了要使用诸如 Log4net, Log4j, Tracer 等东东来写日志，不管用什么，这些东东大多是大同小异的，一般都提供了这样5个日志级别：
× Debug
× Info
× Warn
× Error
× Fatal
一个等级比一个高，但是在具体开发中，关于应该如何选择适应的等级，却没有找到好的文章进行说明。记录一下自己的一些看法，以便日后使用吧。
=== Debug ===
这个级别最低的东东，一般的来说，在系统实际运行过程中，一般都是不输出的。
因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出来看看也无妨。
当然，在每一个 Debug 调用之前，一定要加上 If 判断。
=== Info ===
这个应该用来反馈系统的当前状态给最终用户的，所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
从某种角度上说，Info 输出的信息可以看作是软件产品的一部分（就像那些交互界面上的文字一样），所以需要谨慎对待，不可随便。
=== Warn、Error、Fatal ===
警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的状态，他们之间的区别，要区分还真不是那么简单的事情。我大致是这样区分的：
所谓警告，应该是这个时候进行一些修复性的工作，应该还可以把系统恢复到正常状态中来，系统应该可以继续运行下去。
所谓错误，就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。
所谓Fatal，那就是相当严重的了，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话，可以肯定必然会越来越乱。这时候采取的最好的措施不是试图将系统状态恢复到正常，而是尽可能地保留系统有效数据并停止运行。
也就是说，选择 Warn、Error、Fatal 中的具体哪一个，是根据当前的这个问题对以后可能产生的影响而定的，如果对以后基本没什么影响，则警告之，如果肯定是以后要出严重问题的了，则Fatal之，拿不准会怎么样，则 Error 之。
=== 一些疑惑 ===
不过在实际使用中，基于上面的这种考虑，也还是有一些具体问题。最常见的就是要在最终产品中将输出日志打开到那种级别才算好呢？
例如在应用中有一个输出窗口，一些系统状态信息将被输出到这个输出窗口中。因为 Info 的级别是如此之低，所以为了让用户能够看到有效的输出信息，必须将日志级别开放到 Info 级别。但是 Warn 的级别比 Info 要高，所以用户不得不被迫看到一些 Warn 的信息。而我们其实已经假定，Warn 信息其实并不影响系统的正常运行，这一般只代表系统中存在一些还没有被发现或者修改的小 Bug。这些 Warn 信息会让最终用户困惑甚至恐慌，系统发出警告了，该怎么办？
个人观点，Info 的级别应该比 Warn 更高才对，Warn 信息和 Debug 一样，应该在产品测试和调试时使用，而 Info、Erro 以及 Fatal 则在产品发布后需要继续使用。
目前我所采用的解决方法是，对于 Warn、Error、Fatal 都添加一个相应的系统断言，这样，可以保证当发生这种问题时，在调试阶段，可以立即得到提示。在软件发布以后，这些信息也能被记录到日志文件中去。
{{{
log.Warn("message");
System.Diagnostics.Debug.Fail("警告", "message");
}}}
Debug.Fail 将导致编译为 Debug 输出时，会弹出一个消息警告窗口，这可保证在测试、调试阶段不漏过任何一个潜在的错误。而在发布时，Release 编译的输出不会包括 Debug 语句，这就不会打扰最终用户，而错误信息仍然能通过 log 记录到日志中。
× Debug
× Info
× Warn
× Error
× Fatal
一个等级比一个高，但是在具体开发中，关于应该如何选择适应的等级，却没有找到好的文章进行说明。记录一下自己的一些看法，以便日后使用吧。
=== Debug ===
这个级别最低的东东，一般的来说，在系统实际运行过程中，一般都是不输出的。
因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出来看看也无妨。
当然，在每一个 Debug 调用之前，一定要加上 If 判断。
=== Info ===
这个应该用来反馈系统的当前状态给最终用户的，所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
从某种角度上说，Info 输出的信息可以看作是软件产品的一部分（就像那些交互界面上的文字一样），所以需要谨慎对待，不可随便。
=== Warn、Error、Fatal ===
警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的状态，他们之间的区别，要区分还真不是那么简单的事情。我大致是这样区分的：
所谓警告，应该是这个时候进行一些修复性的工作，应该还可以把系统恢复到正常状态中来，系统应该可以继续运行下去。
所谓错误，就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。
所谓Fatal，那就是相当严重的了，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话，可以肯定必然会越来越乱。这时候采取的最好的措施不是试图将系统状态恢复到正常，而是尽可能地保留系统有效数据并停止运行。
也就是说，选择 Warn、Error、Fatal 中的具体哪一个，是根据当前的这个问题对以后可能产生的影响而定的，如果对以后基本没什么影响，则警告之，如果肯定是以后要出严重问题的了，则Fatal之，拿不准会怎么样，则 Error 之。
=== 一些疑惑 ===
不过在实际使用中，基于上面的这种考虑，也还是有一些具体问题。最常见的就是要在最终产品中将输出日志打开到那种级别才算好呢？
例如在应用中有一个输出窗口，一些系统状态信息将被输出到这个输出窗口中。因为 Info 的级别是如此之低，所以为了让用户能够看到有效的输出信息，必须将日志级别开放到 Info 级别。但是 Warn 的级别比 Info 要高，所以用户不得不被迫看到一些 Warn 的信息。而我们其实已经假定，Warn 信息其实并不影响系统的正常运行，这一般只代表系统中存在一些还没有被发现或者修改的小 Bug。这些 Warn 信息会让最终用户困惑甚至恐慌，系统发出警告了，该怎么办？
个人观点，Info 的级别应该比 Warn 更高才对，Warn 信息和 Debug 一样，应该在产品测试和调试时使用，而 Info、Erro 以及 Fatal 则在产品发布后需要继续使用。
目前我所采用的解决方法是，对于 Warn、Error、Fatal 都添加一个相应的系统断言，这样，可以保证当发生这种问题时，在调试阶段，可以立即得到提示。在软件发布以后，这些信息也能被记录到日志文件中去。
{{{
log.Warn("message");
System.Diagnostics.Debug.Fail("警告", "message");
}}}
Debug.Fail 将导致编译为 Debug 输出时，会弹出一个消息警告窗口，这可保证在测试、调试阶段不漏过任何一个潜在的错误。而在发布时，Release 编译的输出不会包括 Debug 语句，这就不会打扰最终用户，而错误信息仍然能通过 log 记录到日志中。
第4个回答 2020-05-05
手机上log的意思是日志，通常是系统或者某些软件对已完成的某种处理的记录，以便将来做为参考，它并没有固定的格式，通常是文本文件，可以用记事本打开查看内容。
日志，是一个汉语词汇，汉语拼音是rìzhì。基本字义是指工作日志。日志主要发表在网络，详细介绍一个过程和经历的记录。
日志，是一个汉语词汇，汉语拼音是rìzhì。基本字义是指工作日志。日志主要发表在网络，详细介绍一个过程和经历的记录。
相似回答