虽然说有了 XDebug 加 IDE 可以让 PHP 的调试也可以像其他语言一样,但直接在代码里面 var_dump
的做法还是深入人心,毕竟不用花时间做任何配置就可以使用,而且立马见效。
但自带的 var_dump
的『颜值』的确是有点太寒酸…… 虽然 XDebug 对原生 var_dump
输出样式做了一些小优化,但依然就是 0 分和 10 分的区别而已。
一些对美有要求的 PHPer 坐不住了,创造了『第三方』的 var_dump
,比如我以前用过的 Kint,虽然以现在眼光看挺 00 年代的,但当时真觉得甩了原产 var_dump
几十条街。
没隔多久,Symfony2 推出 VarDumper 组件,不仅把『颜值』整到新高度,还提出了便利性。无论是原生 var_dump
还是 Kint 的 dd
,都是直接输出 HTML 内容,很可能会破坏原页面输出的布局;Symfony 的 dump
结合 Symfony 网页调试工具条,直接将 dump
的输出保存下来,放到工具条上面输出,而不影响原有的网页输出。
不仅如此,Symfony dump 还支持在命令行下的显示,也比原厂的好一百倍。
目前流行的还有 Laravel dd,输出的结果跟 Symfony VarDumper 是一样的,应该就是用的 Symfony VarDumper 组件。
不过,无论是原厂还是第三方 var_dump
,目前还是有一个问题:如果我写的是 web API 呢?
在之前,这个问题要想解决一般是通过日志,或者使用步进调试器设置 watch。当然,如果你用的是 Postman 或者类似的浏览器扩展做的 REST 接口调试工具,可能也能直接显示 dump 结果。只不过这么做不够直接,不能拿来即用,或者得用指定的工具,并且依然有可能会有显示问题(毕竟要 mime type 是 text/html
才能漂漂亮亮显示)。而即将发布的 Symfony 4.1,即将优雅得解决这个问题。
Symfony 4.1 的 VarDump 套组增加了一个新的工具,通过创建一个服务来搜集 dump
的信息,有点类似于日志的方式,但好消息是,不用你自己去创建了:
1 2 3 4 5 6 7 | # 直接显示 dump 结果到命令行 $ ./bin/console server:dump [OK] Server listening on tcp://0.0.0.0:9912 # 或者将收集到的 dump 结果保存到 html 文件 $ ./bin/console server:dump --format=html > dump.html |
dump 服务打印出来的信息不仅包含 dump 的变量数据,还包含被执行的文件,或者访问的是什么地址等上下文信息(图片例子第一部分是打开 dump 服务的命令,第二部分是执行自定义的命令之后,命令行出现的 dump 结果,第三部分是访问网站后,命令行出现的 dump 结果)
访问 HTML 页面的结果如下所示:
配置也十分简单,仅需要添加:
1 2 3 4 | # config/packages/dev/debug.yaml debug: dump_destination: "tcp://%env(VAR_DUMPER_SERVER)%" |
眼看 Symfony 4.1 就要发布,用惯了 var_dump
调试的各路 PHP 老司机们是不是有点兴奋呢?
Symfony 4.1 VarDumper —— var_dump 调试流 PHPer 的福音 by Chris Yue is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

文章可赞,扫码赏饭!
天使投赏人
4 Comments
冰翼
四月 18, 2019 在 5:44 下午最近发现一个叫 tracy 的库,可以把调试信息输出到 header,然后配置浏览器插件最终把日志输出到浏览器控制台中。
Chris Yue
四月 19, 2019 在 10:20 上午这个应该是老方法了,印象中老 Symfony 可以开启 Firebug 调试方法,就是用的这种方式,Symfony 输出调试信息到 header,火狐的 Firebug 扩展负责显示。
但用的人并不多,我自己使用的感受也不是很好,一方面可能界面的确没有好好优化,不讨人喜欢。而且还需要解决可能会出现的『头信息过大』的错误。
李
六月 4, 2018 在 10:49 上午居然换了界面风格了
Chris Yue
六月 5, 2018 在 8:24 上午一看公子就是老顾客了,进来玩儿啊