PHP隐错设置不生效的主因是配置未作用于实际运行的SAPI环境，需通过phpinfo()或php -i确认Loaded Configuration File路径，排查php-fpm、user.ini、.htaccess、ini_set()、Docker环境变量等覆盖项。

PHP隐错设置不生效的常见原因

直接改 php.ini 里的 error_reporting 或 display_errors 后重启 Web 服务（如 Apache/Nginx + PHP-FPM）仍看不到错误，大概率不是配置没写对，而是 PHP 实际加载的不是你改的那个 php.ini 文件。

用 phpinfo() 查看 “Loaded Configuration File” 这一行，确认路径；如果显示为 none，说明当前是 CLI 模式或 CGI 模式下运行，或被其他配置覆盖（比如 .htaccess、ini_set()、Docker 环境变量等）。

• php -i | grep "Loaded Configuration File"（CLI 下快速验证）
• Nginx + PHP-FPM 场景下，检查 php-fpm.conf 或 pool 配置里是否设置了 php_admin_value[display_errors] = off —— 这类设置会强制覆盖 php.ini
• 某些宝塔、AMH 等面板会把用户级配置写在单独的 user.ini，优先级高于全局 php.ini，且不随服务重启自动重载，需手动触发或等缓存过期

display_errors=On 但页面还是空白？检查 SAPI 类型和输出缓冲

Web 请求走的是 CGI/FastCGI（如 PHP-FPM），而 CLI 下 display_errors 默认是 On，但 Web 端默认 Off。即使设为 On，也可能被输出缓冲或前端响应头拦截。

• 确认当前 SAPI 是 fpm-fcgi 而非 cli：用 php_sapi_name() 输出判断
• 若用了 ob_start() 或框架自带的输出缓冲（如 Laravel 的 Response 中间件），错误可能被吞掉，加一句 ob_end_flush(); 再触发报错试试
• 部分 Nginx 配置含 fastcgi_intercept_errors on;，会把 HTTP 500 错误转成自定义错误页，关掉它才能看到原始 PHP 错误

error_reporting 设置被运行时代码覆盖

很多老项目或 CMS（如 WordPress、Discuz）会在入口文件开头就调用 error_reporting(0)，或者用 ini_set('display_errors', '0') 强制关闭 —— 这比 php.ini 优先级高，重启服务完全无效。

• 搜索项目中所有 error_reporting( 和 ini_set( 调用，尤其关注 index.php、wp-config.php、common.inc.php 等启动文件
• 临时调试可在出问题的脚本最顶部加：error_reporting(E_ALL); ini_set('display_errors', '1');，绕过前面的屏蔽
• 注意：生产环境切勿长期开启 display_e

  

  rrors，应配合 log_errors = On + 查看 error_log 文件路径

Docker / 容器化环境下的隐错失效特例

镜像里 PHP 配置常通过环境变量或启动脚本注入，php.ini 文件可能只读，或每次容器重建都恢复默认值。

• 检查是否用了 php:apache 或 php:fpm 官方镜像，它们默认禁用 display_errors，且不加载自定义 php.ini，除非显式 COPY 或挂载
• Docker Compose 中常见写法：PHP_INI_DIR=/usr/local/etc/php + 挂载 custom.ini 到该目录，而非直接改 php.ini
• Alpine 镜像中路径常为 /etc/php8/php.ini（版本号要对得上），别按 Ubuntu 路径去猜

真正卡住的点往往不在“怎么设”，而在“设给谁看”——是 CLI？FPM worker？还是某个特定 pool？不先定位实际生效的配置层，改再多遍 php.ini 都白搭。