; This directive controls whether or not and where @R_301_461@ will output errors, ; notices and warnings too. Error output is very useful during development. ; Development Value: On display_errors = On

; Besides displaying errors,@R_301_461@ can also log errors to locations such as a ; server-specific log,STDERR,or a location specified by the error_log ; directive found below. While errors should not be displayed on productions ; servers they should still be monitored and logging is a great way to do that. ; Production Value: On log_errors = On

; Log errors to specified file. error_log = /path/to/@R_301_461@_error.log

开发者调试时已经确定，$fp为空，连接失败，是这一行有问题，但是为什么连接失败？

函数是@R_301_461@自带的，无法进行更深入的调试。所以一般这样的函数（主要是网络通信类的），会自己提供调试参数：$errno和$errstr。你可以加一句：

就能看到连接失败的原因了。

这些函数有：fsockopen，pfsockopen，stream_socket_server，stream_socket_client 等。

还有些函数是调试一个功能用的，比如：MysqL_errno，socket_last_error，socket_strerror 等。

这些只需要了解下，碰到能想到用即可。

二、引进调试工具

在遇到复杂问题时，可以借助调试工具。比较成熟的有Xdebug、ZendDebugger。

以Xdebug为例，它能够：控制打印输出的样式和数组层级、堆栈式的追踪错误、追踪函数调用、代码执行覆盖分析、程序的概要分析（Profiling）、远程调试。详见：。

Xdebug前两个功能是对@R_301_461@原有的调试功能做了改进，更方便调试。

复杂的问题，调试不出来的，可能是业务上的的问题，下面也有说业务逻辑的调试。

三、调试业务逻辑错误

当@R_301_461@脚本跑起来，没有任何错误，只能说它没有语法上的错误，但是不能说明它业务逻辑上没错误。

很多业务逻辑的错误并不会反映在语法错误上，但调试的思路和@R_301_461@自带调试功能差不多。

下面是一些方法。

1、最基本的调试方法

先确定两个东西：程序预期的结果、程序现在的不符合预期的结果； 寻找与两种结果相关的代码片段； 阅读这些代码片段，尝试以“肉眼”找出错误； 找不出，则需要输出一些关键变量，通过检查它们的值是否正确来判断是哪里发生了错误； 若干次尝试，最终你可以确定错误发生在哪个点。

你也可以借助Xdebug等工具，查看变量值的变化，或者设置断点进行调试。

2、记录运行日志

有些复杂或特殊的业务，用上面的方法不合适，比如：一个不能被打断的后台运行脚本。这些情况下记录运行日志比较合适。

记日志的点要有所选择，除了业务上比较重要的点，通常容易出错的地方有：网络连接和通信、系统权限问题等。

3、单元测试

以代码测试代码，而不是像第一点一样调试完会把测试代码丢掉。以测试驱动开发。

这个话题比较大，但适合放这里提一下。有兴趣的同学可以去了解。

四、调试非功能性的错误

非功能性错误，比如：内存溢出导致程序挂掉了、效率有问题导致程序非常慢、死循环了等等。

这些问题，用“肉眼”检查代码效率太低了。

所以可以借助调试工具做程序的概要分析（Profiling），从中检查出程序的瓶颈所在。