IDE调试手段虽必不可少，但远远不够
我们在项目初期的开发联调阶段，会使用IDE工具对代码进行Debug调试，将软件的基本流程和功能调整。由于Debug和Release下存在差异（比如变更是否会自动初始化及内存管理上的差异），有些问题只出现在Release版本中，在Debug下是没有的，这类问题没法通过Debug调试去排查的。
比如在Visual Studio编译的程序中，Debug下会给内存填充默认值，而Release下未初始化的内存中的内容是随机值（申请内存时内存中残留的值）。
对于有些好复现的问题，我们可以进行Release下的调试。此外，除了直接的Debug和Release下的调试，还可以进行附加到进程调试。附加到进程调试，对于调试底层的单个模块是很好用的。
IDE调试是我们处理问题的最直接、最基本的手段，但IDE调试不能覆盖所有的场景，比如产品进入测试或发布上线后，有些问题是很难复现的，所以没法通过Debug和Release调试去排查。
此外，产品上线到客户环境后遇到了问题，某些问题与客户的环境有着直接的关系，即只在客户端环境中才有问题。可能是客户的网络环境、系统版本或特殊的硬件配置导致的，问题只在客户的环境中出现，在我们厂商的内部测试环境中很难复现，像这类问题就不好进行代码调试了，也基本不可能到客户的环境中去调试代码。所以仅仅依靠IDE调试去排查问题，是远远不够的。
通过查看日志和代码去排查异常崩溃问题，费时费力，很难定位问题，为了排查软件在运行过程中遇到的问题，我们会在软件中添加大量的打印日志，软件的运行日志是我们排查问题的重要手段。软件中的异常主要包括两大类：业务逻辑的异常和软件异常崩溃。
对于业务上的异常，可以通过打印日志去排查，通过运行日志去查看软件的运行流程和执行轨迹，还可以将相关变量的值打印出来，根据变更的值去辅助分析。此外，对于某些场景，还需要使用抓包工具去抓网络包分析。
对于软件异常崩溃，在排查手段与方法上，与业务上的异常排查有很大的不同，一般公通过日志打印去排查崩溃问题，是很难定位的。因为日志中没法找到软件的崩溃点，很难找到引发软件崩溃的线索。
日志不是排查软件异常崩溃的主要手段，日志仅仅起到辅助的作用，比如我们在找到软件崩溃点及崩溃时的函数调用的堆栈后，可以通过日志去查看代码的运行流程与轨迹，以及相关变量值去辅助分析引发崩溃的原因（通过打印查看代码的执行逻辑是否正常）。