display_errors=on不生效，需检查三处：一是cli/web环境实际加载的php.ini路径（用php --ini或phpinfo()确认）；二是/etc/php/*/conf.d/等额外加载的.ini文件覆盖；三是web服务器（如apache/.htaccess）或php-fpm中php_admin_flag强制关闭。
php.ini 里 display_errors = On 不生效？检查这三处
PHP 错误不显示，大概率不是 display_errors 没开，而是被更高优先级的配置覆盖了。常见于 CLI 和 Web 两种环境混用、或用了框架/容器导致实际加载的配置文件不是你以为的那个。
- 运行
php --ini看 CLI 加载的配置路径；用phpinfo()页面查 Web 环境实际生效的Loaded Configuration File - 某些 Linux 发行版（如 Ubuntu）会额外加载
/etc/php/*/apache2/conf.d/或/etc/php/*/cli/conf.d/下的 .ini 文件，里面可能有display_errors = Off覆盖主配置 - Web 服务器（如 Apache 的
.htaccess）或 PHP-FPM pool 配置中，可能用php_admin_flag display_errors off强制关闭，这种设置无法被ini_set()覆盖
开发时临时开启错误：用 ini_set() 但要注意时机
ini_set('display_errors', '1') 确实能动态开启，但它只对「当前请求生命周期内后续执行的代码」有效——如果错误发生在 ini_set() 之前（比如 autoload 失败、语法错误、扩展未加载），依然看不到。
- 必须放在最开头，且不能有 BOM 或输出（包括空格、换行），否则报
Cannot modify header information - 仅对
E_NOTICE/E_WARNING等运行时错误有效；Parse error、Fatal error这类解析期错误，ini_set()根本没机会执行 - 搭配
error_reporting(E_ALL)一起用，否则即使显示打开，也可能因错误级别太低而被忽略
为什么开了 display_errors 却只看到白屏？看 error_log
白屏 ≠ 没错误，很可能是错误被写进日志却没显示出来。尤其在生产环境习惯性关掉 display_errors，但忘了开 log_errors，结果连日志都找不到。
- 确认
log_errors = On，并检查error_log指向的路径是否有写入权限（常见于 Docker 容器内 /var/log/php/ 不可写） - CLI 下默认不记录到文件，错误直接打到终端；但加了
-d log_errors=On -d error_log=/tmp/php-error.log就能捕获 -
display_errors = Off时，var_dump()、echo等输出仍正常，别误以为是 PHP 崩了——先看tail -f /var/log/apache2/error.log或对应 Web 服务器错误日志
docker 或宝塔环境下 display_errors 失效的典型表现
这类环境常预装多版本 PHP，并通过软链接或配置代理切换，容易造成「改了配置但没改对地方」。比如宝塔面板修改的是模板文件，实际站点启用的是独立配置副本。
立即学习“PHP免费学习笔记（深入）”；
- Docker 中若用
php:apache镜像，自定义.ini文件需 COPY 到/usr/local/etc/php/conf.d/，且文件名必须以.ini结尾（如debug.ini），否则不加载 - 宝塔用户改完配置后必须点「重载配置」，且要确认右上角 PHP 版本与当前站点绑定的版本一致——不同版本的
php.ini是分开的 - 某些一键脚本（如 LNMP）会把
display_errors写死在php-fpm.conf的php_admin_flag项里，这时改php.ini完全无效
真正麻烦的不是找不到开关，而是错误发生在配置加载前，或者被 Web 服务器层静默吞掉。动手前先跑一遍 php -i | grep -E "(display_errors|error_reporting|error_log|Loaded Configuration)"，比反复刷新页面有用得多。
