定位程序问题和调试

在日常开发中，难免会遇到各种问题及对产品维护的疑难杂症，这时我们就需要定位和解决问题，调试程序是必不可少的环节，固然开发是重要的，但是调试是不可或缺的。
我所学习的是加入日志输出，通过日志输出，了解清楚程序的执行情况，在不是自己开发的程序中也是适用的，从而找出问题所在。对于不懂的运行流程，直接加日志输出，理清运行顺序，定位问题发生的位置，再分析发生问题的具体原因，也就是定位问题所在，以及造成的原因。

FILE：它会被编译器替换为包含当前源文件名的字符串字面量。通常用于在代码中输出当前所在的源文件名。

FUNCTION：它会被编译器替换为包含当前函数名的字符串字面量。通常用于在代码中输出当前所在的函数名。

在 aiinone 中有两个常用的日志输出，也可以用 printf 函数：
CLog::LogU("[%s:%s] \n",FILE,FUNCTION);

这行代码使用了 LogU 方法，通常表示以“信息”级别记录日志。这意味着这条日志消息是一般性的信息，用于记录程序运行状态或关键数据的变化。在输出格式中，"U" 通常表示 "Information" 或 "普通信息"。
CLog::LogW("[%s:%s] \n",FILE,FUNCTION);

// 输出当前源文件名和当前函数名
printf("File: %s, Function: %s\n", FILE, FUNCTION);

这行代码使用了 LogW 方法，通常表示以“警告”级别记录日志。这意味着这条日志消息用于警示开发者或运维人员可能需要关注的问题，但并不是严重到导致程序崩溃或无法正常工作的程度。在输出格式中，"W" 通常表示 "Warning" 或 "警告"。
示例：

解决问题的过程中曲折多磨，但是也学到了怎么定位 bug。过程中，一个思路，以为是问题的原因，尝试解决。发现不可行，于是推翻之前的推断。对于调试程序的方法论不熟悉以及代码理解的不够完整导致思考的方向是错误的。在定位问题的时候，分析原因，没有找到根本问题，而是找到表象，出现的问题，而导致的是更加具体的，以至于要具体到变量值准备好没有，被写入数据的文件准备好没有。

基于我遇到的问题以及解决的过程中遇到的问题，总结其解决方法如下：理清程序运行顺序、分析日志定位具体问题发生位置、分析造成问题的具体原因、提出解决方案并尝试、那种方案更适合解决这个问题