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 优先级高，重启服务完全无效。
立即学习“PHP免费学习笔记（深入）”；
- 搜索项目中所有
error_reporting(和ini_set(调用，尤其关注index.php、wp-config.php、common.inc.php等启动文件 - 临时调试可在出问题的脚本最顶部加：
error_reporting(E_ALL); ini_set('display_errors', '1');，绕过前面的屏蔽 - 注意：生产环境切勿长期开启
display_errors，应配合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 都白搭。
