17370845950

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() 在探针页附近打点验证逻辑流

当怀疑某段代码没执行（比如探针显示正常但功能异常），可在关键位置插入人工触发点：

• trigger_error('Reached config check step', E_USER_WARNING);

• 该错误会写入 error_log，且不会

  

  中断流程，适合灰度验证
• 避免用 echo 或 var_dump，它们可能被缓冲、被模板拦截，而 trigger_error 强制落地到日志
• 注意不要在生产探针文件里长期留这类调试代码，容易被扫描到

真正卡住的时候，往往不是探针数据不准，而是错误被静默吞掉、日志路径被覆盖、或错误级别低于当前 error_reporting 设置——盯住 error_log 文件权限、SELinux 状态（Linux）、以及 FastCGI 进程用户能否写入目标路径，比反复刷探针有用得多。