PHP调试利器：print_r与var_export到底该怎么选？

写PHP这些年，翻车排查时十次有九次会习惯性敲下print_r()。控制台刷出一大坨带缩进的数据，看着清晰，可一旦遇到对象相互引用，内存直接原地报警。这时候若换成var_export()，吐出来的又是能直接跑通的语法字符串，肉眼阅读格外费劲。很多人卡在这一步就停了，其实这两兄弟各管一摊，摸清脾气能省下大量无效试错时间。

日常核对数组结构、看接口解码后的嵌套层级，print_r是效率最高的选择。它的排版天生适合人眼扫视。配合将第二个参数设为true，它能跳出输出限制，把排版好的内容完整打包成字符串交还给你。把敏感信息或复杂数据结构写入日志文件时，这么写最稳：

$logLine = print_r($payload, true);
file_put_contents('debug.log', date('Y-m-d H:i:s') . ' - ' . $logLine . PHP_EOL, FILE_APPEND);

切记它不是万能扫描枪。碰到数据库连接、文件句柄这类resource资源，它会立刻停笔只显示“Resource id #5”，后续字段全部屏蔽。

需要固化数据状态、生成缓存文件，或者想把调试结果原样贴回源码继续迭代，var_export才是正解。它严格遵循PHP语法规范：布尔值输出大写TRUE/FALSE，空值转NULL，数组索引与关联键名自动补全引号。同样依赖第二个参数设为true，它不往屏幕砸内容，而是安静返回生成的代码片段：

$stubCode = var_export($staticConfig, true);
file_put_contents('cache/stub.php', "<?php\nreturn " . $stubCode . ";");

这套组合拳在搭建项目骨架、持久化规则引擎或做轻量级配置中心时极省力气，避免了手拼字符串导致的括号错位风险。

业务量上来后，踩坑点往往藏在边缘逻辑。对象链式引用会让两者陷入无限递归，PHP默认抛出栈溢出终止运行。此时套一层浅层遍历拦截器，或者直接限定最大递归深度即可破局；纯抓取核心字段时，自定义过滤数组反而更干净。线上环境务必给这些调试语句装上闸门。高并发下频繁的全局字符串构造与磁盘IO会悄悄蚕食响应带宽，甚至撑满日志分区。用环境变量或IP白名单做路由开关，确保生产流量永远绕开打印逻辑。遇到超大体积载荷或含特殊二进制的响应，先做切片截断再注入打印函数，终端闪退的概率能直降九成。

调数据就像理顺一团毛线，看清节点再下剪刀。图快看图用print_r(true)收口，要留痕要复用用var_export(true)接力。守住参数开关和隔离红线，排查路径自然清晰。下次再面对满屏乱跳的嵌套结构或突然中断的执行流，顺手切换对应的函数，卡脖子的问题通常瞬间松绑。