php开发，你是如何做调试的，希望看到此问答的PHPer都留个言
做个 PHP 开发调试问卷调查
背景
php 是解释执行语言，因而并不能像一般编译类语言能直接在 IDE 下开启断点调试，因而 PHPer 的调试分为：
- 靠人脑
- 封装个含有 print_r()、 die() 打印输出函数; 或 composer require symfony/var-dumper 引入 dump()。（ laraval框架下可用dd() ）
- 开启 Xdebug 扩展，在 IDE 下断点调试
简单情况下，其实什么调试方式都行，但要是我们工作中阅读与写代码时常需要调试，我们还能不注重调试效率吗？
参与调查
为节省愿意参与问卷调查 PHPer 的时间，与方便查看评论，定下回答格式：
第一个问答：调试方式
第一行：我的调试方法：主调试方法（可加：辅调试方法）
第二行：理由 或 推荐使用何种调试方法
另外加个，是否必要开启 Xdebug 的断点调试，回答格式：
第二个问答：是否必要用 Xdebug 开启断点调试
第一行：xdebug: -1 或 0 或 1 （-1.根本不需要 0.可有可无 1.必要）
第二行：理由：理由说明
以上，你可以只回答一个，如果两个都回答，中间用空行把两者隔开下，第一个是调试方式，第二个是否必要用 Xdebug 开启断点调试。
感谢你的参与~
关于 LearnKu
粤公网安备 44030502004330号
xdebug: 1
一劳永逸
我个人的情况： 开发环境 99% 使用 dump, dd 1% 使用 xdebug
xdebug在找一些库的问题的时候或者追踪代码嵌套层数很多的非常好用，一般问题框架自身的debug功能和dump打印功能足够使用了。xdebug必须装，但是不是所有问题都需要使用xdebug。比如我在使用pay这个扩展做微信支付的时候，它的错误提示很简单，简单到不会把微信的错误信息返回给我，使用xdebug就能轻松追踪到。当前你愿意去读源码，里面找打印出来也是可以的。类似Array to string conversion是没必要使用的。在日常中，开发环境虽然安装了
xdebug了，但我的使用频率并不是很高。我的调试方法：xdebug
理由：高效快捷；若用 dump, dd 还要在需要的代码处加上，调试完再删除…
xdebug: 1
理由：自从使用后，就回不去了，谁用谁知道，哈哈哈；对于容器框架，在 xdebug 帮助下，你可以清晰观察到当前容器内的参数，想去研究它时，可以做到更快更直白知道它干了什么怎么做到的
PHP STORM 几乎 0 配置，装个 Xdebug 就算上网络因素，也只需要 10 分钟，尤其是在现代化框架的加持下， Xdebug 带来的受益远大于直接打印。
如果只是开发过程中需要看看数据，那打印基本上也够用了，但是如果要复杂的调试，那还是得用 Xdebug。
靠意念
print_r()，var_dump, echo 打印简单的，看心情使用； 当涉及到多个类时，就用xdebug
用的99%都是dd，xdebug愣是配置不来
我们是分场景来调试的。
正式场：全部都是看阿里云的SYS日志。
非正式场：API响应多了一个debug字段，里面有上下文信息、手动添加的调试信息，会偶尔看一下SYS日志。
都用
自己的代码在99%的情况下 dd就解决了 别人的代码 太长太复杂直接xdebug一劳永逸
dd和日志
曾经尝试用过xdebug，发现用起来很麻烦，后面放弃了。
如果需要调试，一般是记日志，开发环境记日志级别debug，线上日志级别设置高些，这样互不影响。
如果功能开发完成了，可以去掉debug级别的日志。
逻辑熟悉就dd和日志,不熟悉就xdebug。
比较陌生或比较长的代码用xdebug，不过不兼容swoole； 熟悉了就 dump exit 了；
swooleyou 自己的调试工具~socketlog 自己封装异常 封装调试函数记录数据库 在数据库里看
大多数情况用var_dump和file_put_contents调试。xdebug很少用
日志yyds
xdebug香啊
xdebug 很强大很方便，配合phpstorm的http request，几乎0配置
用 xdebug 做断点调试，用 Ray 做变量输出
基本上就是dump和dd，xdebug调试通了，不会用 :sob:
debug_backtrace 函数调试或者dump
配置xdebug，然后就开始靠意念了 :smile:
dd()
dump()
dd+xdebug
dd
print_r()
dubug现在还不会配置
xdebug
两者都用，
dd( ...vars )或者dump()var_dump(1);die;
print_r 哈哈，我赞同xdebug很强大，但至少现在用的频率很低，可能我维护的项目没那么复杂吧
dump dd
90% 情况下使用dd，10% 情况用xdebug
dd，可以快捷定位问题位置，能输出一些可以持久查看的内容，有时候边看数据结构边写代码，就靠他了。
xdebug，对于一些复杂的问题，甚至都不清楚问题出在哪的bug，不抛异常的业务逻辑问题，就用这个了，可以详细看到每个步骤的数据变化，精确定位问题，就是点来点去麻烦了些。
另外，
debug=truelaravel自带的debug_trace有时候也很有用dd+log