var_dump 显示变量完整运行时状态（类型、长度、引用等），print_r 仅提供人眼可读的结构快照；调试API或JSON时优先用var_dump，线上环境需用ob_start()包裹，print_r($obj)不显示私有属性，var_dump则完整列出。
var_dump 会输出类型和长度，print_r 只管结构
调试时看到 var_dump 打印出一堆 string(5) "hello" 或 int(42)，而 print_r 就是 hello、42 —— 这不是“谁更简洁”的问题，是底层行为差异：var_dump 是给开发者看变量的完整运行时状态，包括类型、长度、嵌套层级、是否引用；print_r 的设计目标其实是“人眼可读的结构快照”，连布尔值都显示成 1 和空字符串，false 直接消失。
常见错误现象：print_r($arr) 看起来数组是空的，但实际有 false 或 null 值；或者对象属性没显示出来（默认不递归显示私有/受保护属性）。
-
var_dump永远显示真实类型，print_r对false、null、空数组等容易“静默”或简化过度 - 调试 API 返回或 JSON 解码结果时，优先用
var_dump，避免把NULL误判为“没返回” -
print_r($obj, true)可捕获返回值，var_dump没有等效参数，必须用输出控制函数包裹
调试线上环境别直接 echo var_dump
在 Web 请求中裸调 var_dump($data)，尤其在响应头已发送后，会触发 Warning: Cannot modify header information；更糟的是，如果 $data 是大数组或对象，HTML 页面会被一堆调试信息撑爆，前端 JS 可能直接解析失败。
使用场景：开发阶段快速瞄一眼没问题，但只要涉及 AJAX、JSON 接口、CLI 脚本或任何非纯 HTML 上下文，就必须隔离输出。
立即学习“PHP免费学习笔记（深入）”；
- 加
ob_start()+ob_get_clean()包裹var_dump，再写入日志或响应体特定字段 - CLI 脚本里用
var_dump安全，但注意它默认输出到stdout，别和正常业务输出混在一起 - 想临时停用所有调试输出？别注释掉每一行，统一用
if (defined('DEBUG') && DEBUG) { var_dump(...); }
print_r 显示对象时默认不展开私有属性
print_r($obj) 默认只显示公有属性，且不会标明属性可见性；var_dump 则原样列出所有属性，私有属性带 ClassName$property 格式，受保护属性带 *property，一目了然。这是很多人用 print_r 调试 Laravel 或 Symfony 对象时“找不到数据”的根本原因。
性能影响：两者对大对象的递归深度一致，默认都不限制，但 var_dump 多做的类型标注会让输出体积略大，对内存无实质压力，别担心。
- 确认对象结构用
var_dump，写文档或给协作同事看简明结构才考虑print_r - PHP 8.0+ 中
var_dump支持Xdebug扩展增强，能折叠、搜索、高亮，print_r无此能力 - 不要依赖
print_r的返回值做逻辑判断，它对资源类型（如mysqli连接）返回Resource id #n，无法还原
替代方案：debug_zval_dump 和 error_log 更适合生产排查
debug_zval_dump 显示引用计数和是否为引用，平时几乎用不到，但当你怀疑变量被意外引用导致修改不生效，或 unset 后内存没释放，它比 var_dump 多一层线索。而 error_log(print_r($data, true), 3, '/tmp/debug.log') 这种组合，才是真正适合线上灰度排查的方式——不干扰响应流，还能按时间追日志。
容易踩的坑：error_log 写文件需确保目录可写，且 PHP 配置中 log_errors = On；debug_zval_dump 在 PHP 8.4+ 已标记为废弃，别在新项目里用。
- 调试循环引用或 GC 行为，用
debug_zval_dump，其他时候没必要 - 日志路径别硬编码，用
sys_get_temp_dir()或配置项动态拼接 -
print_r($data, true)的第二个参数必须是true，漏写就直接输出到页面，不是返回字符串
最常被忽略的是输出位置和上下文：同一个 var_dump，在 CLI、FPM、Swoole 下表现可能不同；同一段代码，在 Xdebug 开启和关闭时，var_dump 的格式、截断行为也不一样。别假设它“总是那样”。
