跨平台PHP调试器设计及使用方法—

经过之前六篇博文的分析和介绍，大家应该对这套调试器有个初步的认识。本文我将讲解它的使用方法。（转载请指明出于breaksoftware的csdn博客）

上图是该软件界面的布局，我们之后的讲解也将围绕着这些功能展开。

文件夹管理

在查看一个功能代码前，我们往往需要知道其逻辑所在的路径。文件夹管理功能就是提供给用户设置代码逻辑路径的地方。用户可以在这个功能里管理需要调试的代码工程路径。

新增目录

点击文件夹区域第二个按钮，弹出一个对话框，我们可以在输入框中输入一个目录，然后点击Save。这样新目录就加进来了。

删除目录

首先选择一个根文件夹，然后点击文件夹区域第三个按钮，这样就在调试器中删除了该目录的查看。

这块的逻辑见phpdebugserver.py的request_files_tree函数。ide_config.py文件是实现路径增删读的实现模块，它直接操作的是ide.cfg文件中folders区域。

查看代码

作为一个可视化的调试器，查看被调试源码是基础功能。我们可以通过单击文件夹管理区域中文件名来展现文件内容。

调试开关

调试开关是一个非常必要的设置。我们在一台机器上搭建了调试服务后，并不是每次请求都是要调试的。在需要调试的时候，我们可以开启这个开关。这个时候调试器的状态机根据是否设置了断点来决定调试的方式。

如果设置了断点，则进入调试状态后一直运行，直到遇到断点而中断。比如我们在2,3,4行设置了断点，启动调试后，程序会中断在第3行

如果没有断点，则中断到第一行代码。

当调试开关关闭时，调试功能键全部没禁用。

反之则全部被启用。

调用堆栈

调用堆栈可以帮助我们回溯函数的调用过程。比如某一个函数在代码中多个地方被调用，而本次调试时它的内部正好出错，可能是入参错误，这个时候我就需要回溯下调用堆栈，看看哪个地方调用此函数出错的。下图是我们调用到checkNum函数时的调用堆栈信息，它显示在综合信息区域

变量

变量查看是我们在调试过程中经常使用到的功能。当我们逻辑中断在某一行代码时，我们可以通过综合信息区域的变量窗口查看相关变量。默认的，我只是显示了当前堆栈上的变量和全局变量，比如下面一段逻辑

dd();function checkNum($number)
{if($number>1){throw new Exception("Value must be 1 or below");}return true;
}function dd() {try{checkNum(2);//If the exception is thrown, this text will not be shownecho 'If you see this, the number is 1 or below';}catch(Exception $e){echo 'Message: ' .$e->getMessage();}
}

当我们调用到异常抛出行时，我们此时的堆栈上只有一个临时变量

但是此时，该函数外层还有两个调用堆栈，而这两个调用堆栈（见“调用堆栈”节中的图）上的参数是默认不显示的。因为它的数据量可能比较大，而且可能没太多必要，所以我默认把它关闭了。当然我也提供的开启全栈数据的开关。用户可以在Tools的Setting中开启All Stack Parameters功能

断点

断点也是调试器非常基础的功能，我支持了除了watch类型之外的所有其他断点形式。

行断点

新增行断点有三种方式。一种是在代码区域的行号上点击一下

还有一种方式是在综合功能区域Breakpoint的Tab中点击“新增断点”按钮

还有一种是在行号上右击，然后选择“Add Line Breakpoint”。该操作还是会弹出上面这个窗口设置断点信息。

我们可以通过综合信息区域的Breakpoint页面查看断点信息

删除断点操作也非常简单。我们可以在已设置断点的行号上点击一下，或者在综合信息区域的Breakpoint页对断点执行delete操作。

函数调用断点

当我们需要调试某函数时，我们可以设置函数调用断点。这样一旦函数被调用到，就会被中断到函数最开始执行处。我们可以通过新增断点窗口对dd这个函数设置函数调用断点。

我们在第7行调用了dd，最终程序断在dd函数执行的第一行，即21行。

函数返回断点

顾名思义，函数返回断点是断在指定函数的返回处。我们还以dd这个函数为例。

当这个断点被命中后，此时调试器尚不处在代码中，我们可通过调用堆栈看到

此时，我们需要执行一下step over让调试器进入代码中。从下图可见，绿标的那行就是执行完dd函数后应该要被执行的代码。

异常断点

异常断点是用于帮助我们在异常发生前中断的断点。比如我们程序中使用异常方式终止流程执行，则可能在代码很多地方遍布异常抛出逻辑。而本次调试时最终在何处抛出异常，则比较难以定位。这个时候异常断点就是一个非常好的方案。我们以抛出Exception类型异常为例，首先我们要在断点设置窗口中设置断点信息

然后触发调试，可以发现流程中断在抛出异常的地方。此时我们便可以分析上下文和变量信息查看异常的原因。

条件断点

条件断点也是可以帮我们解决繁琐问题的一个方案。比如我们在一个循环中调用一个函数，我们希望这个函数在循环中被调用67次时被中断。那么如果我们在函数上下断点，则可能之前66次中断是没用的，还要不停的在中断后点击Run。这个过程实在太繁琐。条件断点就可以帮我们解决这个问题。我们只要在中断所在行设置条件，比如设置迭代索引为67时中断。下面例子我们以迭代索引为6为例

触发调试后，我们可以发现中断在第32行。而且通过变量查看器，我们可以发现此时$i的值为6。

变量修改

变量修改功能是调试时人为修改变量值从而影响逻辑执行流程的功能。比如上例介绍异常断点时，我们判断$number是否大于1，如果大于则抛出异常。如果我们在调试时不想此时抛出异常，则可以修改$number的值。首先我们在第11行下断点，并触发调试。我们查看下此时变量的值

我们右击变量查看器中$number的值，弹出下面的窗口

我们修改$number的值为1

点击保存，我们在查看变量查看器，并执行一次step over。可以看到$number已经变成1，而且之后也没走抛出异常的逻辑。

变量前后对比功能

这个功能也是默认关闭的。因为它需要保存中断前后两步的全栈变量，这个操作非常耗时。我们可以通过Tools的Setting中的Variables Watch开关开启此功能。我们还需要开启All Stack Parameters功能。

我们在第4行下断点，同时将$a添加到变量监控中

点击综合信息区的Variables Watch页，并触发调试，此时$a在调试前后都没值

执行一次step over操作，让第4行被执行

此时$a被修改为123了。左侧区域是第4行被执行之前的值，右侧是第4行被执行之后的值。我们继续step over两次。看看之后的变化

文件监控功能

当我们调试一个功能时，可能还需要查看一些文件变化，比如我们可能需要监控一些日志文件。此时我们可以使用综合信息区的Files Watch功能。

该文件会随着我们调试进行而变化，我们在该Tab页下也将看到文件变化的过程（手工点击刷新，也可以做成自动）。

请求记录和发送

这个功能是为了记录调试时请求并模拟该请求而设计的。当我们从网页中触发一些请求前，我们可能需要填写一些数据。一次调试后，这些数据将不在页面中存在，而需要重新填写并提交，这个过程非常麻烦。我们可以在调试过程中记录请求内容，并制定请求路径，从而达到记录功能。

比如我们发送http://127.0.0.1/index.php?pamra1=value1&param2=value2请求，我们在变量查看器中可以看到

我们点击请求记录按钮，并该该请求命名

在主界面右侧的变量记录区域我们可以看到它的信息。点击笔状编辑按钮，我们将Url路径和发送方式填入

点击保存即可。我们还可以对变量进行增删改，比如我们增加一个变量param3=value3，则

我们让此次调试结束。然后再次打开上面请求编辑界面，点击Send按钮。此时会新打开一个页面发送请求，然后我们的调试器中断后会在变量区域显示新的请求参数