php报错不显示需先开启错误报告：设php.ini中display_Errors=on、error_reporting=e_all；若不可改配置，可用error_reporting(e_all); ini_set(‘display_errors’,’1′);并启用log_errors和error_log定位问题；语法错误要查报错行前几行的符号匹配。
PHP报错不显示？先确认错误报告开关是否打开
很多情况下根本看不到报错，不是没出错，而是PHP默认关掉了错误显示。尤其在生产环境，display_errors 通常设为 Off，导致白屏或500却无提示。
- 开发时务必在
php.ini中设：display_errors = On，并确保error_reporting = E_ALL - 若无法改配置，可在脚本开头加：
error_reporting(E_ALL); ini_set('display_errors', '1');（仅对当前脚本生效） - 注意：某些主机禁用
ini_set，此时必须靠配置文件或 .htaccess（apache）：php_flag display_errors on -
log_errors = On和error_log = /path/to/error.log是必配项，白屏时唯一能查的线索就在这儿
Parse error: syntax error, unexpected… 怎么快速定位
这类语法错误会让PHP直接拒解析，连error_log都可能不写——因为根本没执行到日志逻辑。关键在“unexpected”后面的符号或关键字，它往往不是错误本身，而是**上一行漏了分号、括号未闭合、引号不配对**等导致的连锁误判。
- 用编辑器开启括号高亮和行尾空格显示，重点检查报错行的前3行
- 常见陷阱：
echo "a" . "b"后面多打了一个逗号；function foo() {忘了闭大括号，但报错却在文件末尾 - 命令行下用
php -l yourfile.php可静态检测语法（比刷新页面快得多） - 如果用了短标签
却没开short_open_tag，也会报 parse error，改用<?php最稳妥
Warning: Undefined array key 或 Notice: Undefined variable 怎么安全处理
这类不是致命错误，但暴露代码健壮性问题。直接访问未声明的数组键或变量，在 PHP 8+ 默认会报 Warning，而旧版是 Notice，容易被忽略。
- 别用
@抑制（如$val = @$arr['key'];），它拖慢性能且掩盖真实问题 - 正确做法：用
isset($arr['key'])或 PHP 7+ 的空合并操作符$arr['key'] ?? 'default' - 变量未定义？先
var_dump($var)确认作用域——函数内没 global，或超全局变量（如$_POST）拼错名，都很常见 - 注意：PHP 8.0+ 对未初始化变量读取直接报 Warning，不能再靠“默认为 null”侥幸
500 Internal Server Error 但 error_log 为空？检查 Web 服务器与 PHP 模块协同
这往往不是PHP代码问题，而是环境层断裂。比如 Apache 加载了损坏的扩展，或 Nginx 配置里把 .php 文件当静态资源返回了，压根没交给 PHP-FPM。
立即学习“PHP免费学习笔记（深入）”；
- 先看 Web 服务器错误日志：
/var/log/apache2/error.log或/var/log/nginx/error.log，里面常有“Failed to load extension”或“connect() to unix:/run/php/php-fpm.sock failed” - 运行
php -m检查扩展是否加载成功；php --ini确认实际加载的是哪个php.ini - Nginx 常见漏配：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;缺失会导致脚本路径为空，直接500 - SELinux 或 AppArmor 开启时，可能阻止 PHP 访问文件或 socket，临时用
setenforce 0测试是否为此类权限问题
调试 PHP 错误最耗时的环节，往往不在代码逻辑，而在“到底哪一层在报错”——是 PHP 解析器、扩展、Web 服务器，还是系统权限。每次遇到黑盒500，先切到服务器日志，再切到 PHP 配置，比反复改代码有效得多。