php 8.5.5 报错不显示并非版本问题，而是 display_errors、error_reporting、display_startup_errors 三者配置未生效或被覆盖；其中 display_errors = off 是空白页主因，error_reporting 级别过低会过滤警告，display_startup_errors 未开启则无法捕获解析错误。
display_errors = Off 是默认且最常见原因
哪怕你改了 error_reporting，只要 display_errors 是 Off，所有错误（包括 Parse error 和 Fatal error）都不会输出到页面——你看到的只是空白页或 500 错误。
- 开发时必须设为
On；生产环境必须为Off，但需配合日志 - 注意：PHP-FPM 模式下，
php_admin_flag display_errors on可能覆盖 php.ini 设置，要查www.conf里的 pool 配置 - Apache 下可用
.htaccess：php_flag display_errors on，但部分托管环境禁用该指令
error_reporting 级别太低或被代码覆盖
error_reporting 决定哪些错误“值得报”，如果设成 0 或 E_ERROR，Notice 和 Warning 就直接被过滤掉——而 PHP 8.5.5 默认对未定义数组键、变量等会触发 Warning，不是静默忽略。
- 开发期推荐：
error_reporting = E_ALL（不要加& ~E_NOTICE这类屏蔽） - 检查是否在
vendor/autoload.php或框架入口前就调用了error_reporting(0)—— 它会全局生效，且无法被后续ini_set()覆盖 - CLI 和 FPM 加载不同 php.ini，用
php --ini和php -r "echo ini_get('error_reporting');"分别验证
Parse error 和 startup error 必须靠 display_startup_errors
像 Parse error: syntax error, unexpected '}' 或 Fatal error: require(): Failed opening required 'xxx.php' 这类错误，发生在脚本加载阶段，ini_set('display_errors', '1') 根本来不及执行——它们只响应 display_startup_errors。
- 必须在 php.ini 中设：
display_startup_errors = On（仅 php.ini 有效，ini_set()对它无效） - 这个开关常被遗忘，尤其在 phpEnv 或 Docker 环境中，默认是
Off - 验证方式：故意在入口文件第一行写个语法错，比如
<?php echo不闭合，看是否报错
log_errors 配置错误导致“以为没错”
当 display_errors = Off 且 log_errors = Off 或 error_log 路径不可写时，错误既不显示也不记录——你什么也看不到，误以为“没出错”。
- 确认
log_errors = On，并检查error_log路径是否存在、PHP 进程用户（如www-data）有写权限 - FPM 和 CLI 的日志路径不同：
php-fpm通常走www.conf里的php_admin_value[error_log]，CLI 默认输出到终端，除非显式配置 - 用
tail -f /var/log/php_errors.log实时观察，再触发一个trigger_error('test', E_USER_WARNING);看是否落日志
php -i | grep -E "(display_errors|error_reporting|display_startup_errors|log_errors|error_log)"，比猜强十倍。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
