PHP启动阶段崩溃导致白屏，error_reporting和display_errors未生效；需在php.ini中设display_errors=On、error_reporting=E_ALL并重启Web服务，或在index.php顶部添加ini_set指令。
白屏时没有错误提示，error_reporting 和 display_errors 为什么没用？
phpmyadmin 白屏但不报错，大概率是 php 在启动阶段就挂了——比如扩展没加载、语法错误在 config.inc.php 里，或者 session.save_path 不可写。这时候 error_reporting 和 display_errors 根本没机会生效。
实操建议：
- 直接在
php.ini中确认display_errors = On且error_reporting = E_ALL，改完必须重启 Web 服务（不是重载） - 临时在
index.php顶部加三行（放在 error_reporting(E_ALL);<br>ini_set('display_errors', '1');<br>ini_set('log_errors', '1'); - 检查
phpinfo()页面里的Loaded Configuration File路径，确保你改的是这个php.ini，不是其他环境的 - 如果连
phpinfo()都打不开，问题更底层：PHP-CGI 崩溃、内存不足、或 SELinux/ACL 拦截了文件读取
mysqli 扩展未启用导致白屏，如何快速验证？
phpMyAdmin 4.9+ 强制依赖 mysqli（不再支持 mysql），但很多旧环境默认只开 pdo_mysql 或压根没启 mysqli。它不会报“扩展缺失”，而是静默失败、返回空响应。
实操建议：
- 运行
php -m | grep mysqli，没输出就说明没启用 - Debian/Ubuntu：执行
sudo phpenmod mysqli；CentOS/RHEL：检查/etc/php.d/下是否有mysqli.ini，或手动在php.ini加extension=mysqli - Windows 用户注意：
extension=php_mysqli.dll的路径必须和extension_dir一致，且 DLL 文件真实存在 - 启用后务必检查
phpinfo()页面中是否出现mysqli模块区块，而不仅是“已加载”字样
升级后白屏，config.inc.php 里的常见语法雷区
从 phpMyAdmin 4.x 升到 5.x+ 后，config.inc.php 中部分配置项已被移除或改名，一个错位的单引号、多写的分号，或用了废弃的 $cfg['Servers'][$i]['auth_type'] = 'http'（5.2+ 已弃用），都会让整个入口脚本 parse error。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 用
php -l config.inc.php检查语法，别靠肉眼扫 - 重点排查：
$cfg['blowfish_secret']是否为空字符串（必须至少 32 字符）、$cfg['Servers'][$i]['host']是否漏写、/* */注释是否跨了 PHP 开始标签 - 临时把
config.inc.php重命名为config.inc.php.bak，访问看是否恢复（若恢复，说明配置文件是唯一问题源） - 新版推荐用
setup/向导生成配置，而不是手写——尤其当$cfg['Servers']数组嵌套层级变深时
Apache + PHP-FPM 场景下，open_basedir 限制引发白屏
白屏无日志，phpinfo() 正常，但 phpMyAdmin 目录下任何 PHP 脚本都空响应——很可能是 open_basedir 锁死了路径，导致 require_once 加载核心类时被拒绝，PHP 直接退出而不抛异常。
实操建议：
- 在 Apache vhost 或 .htaccess 中搜
php_admin_value open_basedir，临时注释掉测试 - 如果必须保留限制，需显式加入 phpMyAdmin 所有依赖路径：
/usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/dev/urandom - 注意：FPM pool 配置中的
php_admin_value[open_basedir]优先级高于 Apache 指令，得去www.conf里改 - 配合
tail -f /var/log/php-fpm/www-error.log实时观察，这类限制通常会在 FPM 日志里留一句 “failed to open stream”
最麻烦的不是找不到错在哪，而是错发生在 PHP 解析器还没来得及吐错误信息之前——所以白屏的第一反应不该是调代码，而是先看 PHP 是否真跑起来了。
