PHP应用副本实例出现构造函数弃用500错误，主实例正常求排查方向

以下是针对你的问题的具体排查方向：

• 验证PHP运行时配置的实际生效值
  不要只依赖php.ini的配置，在两个实例中分别创建包含<?php phpinfo(); ?>的文件，访问后对比以下关键配置项：

  • error_reporting：确认副本的实际值是否和主实例一致（主实例应该是E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED）
  • display_errors、log_errors：检查是否有虚拟主机级别的配置覆盖了php.ini的设置
  • PHP_INI_SCAN_DIR：确认副本是否额外加载了其他ini配置文件，导致错误级别被修改

• 检查Apache模块与虚拟主机配置差异

  • 执行apachectl -M对比两个实例的加载模块，确保php7_module（或对应PHP版本的模块）已加载，且没有额外的错误处理模块
  • 对比主实例和副本的虚拟主机配置文件，检查是否存在php_value、php_flag这类覆盖PHP配置的指令，比如主实例可能在虚拟主机中单独设置了php_value error_reporting 32759（对应E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED的数值）而副本未添加

• 排查FatFree框架的运行环境差异

  • 检查框架的配置文件（如config.ini或代码中的全局设置），对比DEBUG、ERROR_LEVEL参数：主实例可能设置了DEBUG=0或ERROR_LEVEL=32759，而副本的DEBUG模式开启导致deprecated错误被触发为致命错误
  • 清理副本的框架缓存文件（通常在tmp/目录下），主实例的缓存可能已经规避了构造函数的初始化逻辑，而副本首次运行时重新解析类文件触发错误

• 检查文件权限与所有者

  • 对比应用目录及文件的所有者、权限：主实例的文件可能属于apache/www-data用户，而副本的文件所有者为root，导致PHP无法正常读取框架类文件，间接引发错误
  • 确保tmp/、logs/等框架需要写入的目录具备可写权限，权限不足可能导致错误日志无法记录，进而抛出500错误

• 验证PHP扩展的一致性

  • 执行php -m对比两个实例的已加载扩展，确保FatFree框架依赖的扩展（如pdo、pdo_mysql、mbstring等）在副本中已安装且版本一致
  • 部分扩展的缺失可能导致SQL类初始化失败，同时触发构造函数的deprecated错误，最终表现为500

• 检查Apache的错误日志细节
  查看副本Apache的错误日志（通常在/var/log/apache2/error.log），除了构造函数的deprecated提示外，可能存在其他致命错误信息（如类文件无法找到、数据库连接失败等），这些才是导致500错误的真正原因，deprecated提示可能只是伴随输出

内容的提问来源于stack exchange，提问作者prosto.vint