php探针仅显示环境信息，不处理错误；定位错误需组合配置error_reporting和display_errors、查error_log路径并用tail -f实时跟踪，辅以trigger_error打点验证。
PHP探针本身不处理错误，它只是显示运行环境信息；真要快速定位错误，得靠错误报告配置、日志路径和实时调试组合使用。
开启 display_errors 和 error_reporting 临时查看报错
探针页面看不到具体 PHP 错误，是因为默认关闭了错误显示。开发阶段必须手动打开：
-
display_errors = On（在php.ini或用ini_set('display_errors', '1')） -
error_reporting = E_ALL（或error_reporting(E_ALL)） - 注意：线上环境严禁开启
display_errors，否则敏感路径、变量可能暴露 - 如果用了
ini_set()但没生效，检查是否被php_admin_flag（如 Apache 的php_admin_flag display_errors on）覆盖
查 error_log 路径比看探针更直接
探针里只显示 error_log 配置值，但不自动读取日志内容。定位错误真正靠的是去翻这个文件：
- 先确认当前生效的
error_log路径：echo ini_get('error_log'); - 常见位置包括：
/var/log/php_errors.log、/usr/local/var/log/php/error_log、或项目根目录下的php_error.log - 若返回空字符串，说明错误日志被重定向到 Web 服务器日志（如 Apache 的
error_log或 Nginx 的error.log），需同步查对应服务日志 - 用
tail -f实时跟踪：tail -f /var/log/php_errors.log
用 trigger_error() 在探针页附近打点验证逻辑流
当怀疑某段代码没执行（比如探针显示正常但功能异常），可在关键位置插入人工触发点：
立即学习“PHP免费学习笔记（深入）”；
trigger_error('Reached config check step', E_USER_WARNING);- 该错误会写入
error_log，且不会中断流程，适合灰度验证 - 避免用
echo或var_dump，它们可能被缓冲、被模板拦截，而trigger_error强制落地到日志 - 注意不要在生产探针文件里长期留这类调试代码，容易被扫描到
真正卡住的时候，往往不是探针数据不准，而是错误被静默吞掉、日志路径被覆盖、或错误级别低于当前 error_reporting 设置——盯住 error_log 文件权限、SELinux 状态（Linux）、以及 FastCGI 进程用户能否写入目标路径，比反复刷探针有用得多。
