快速定位PHP 500错误需先查error_log日志，确认php.ini中log_errors=On、error_reporting=E_ALL且display_errors=Off；再检查Web服务器权限、Nginx路由配置（如try_files）及PHP-FPM状态。
PHP 短链接还原服务返回 500 错误，不是代码逻辑写错了就是环境或配置出了问题——直接看 error_log 最快。
怎么快速定位 PHP 报错源头
500 是服务器内部错误，PHP 自身没把错误打到响应体里，而是记在了日志中。别急着改代码，先确认日志在哪、有没有开启记录：
-
error_log路径由php.ini中的error_log指令指定，常见位置有：/var/log/php_errors.log、/var/log/apache2/error.log（Apache）或/var/log/nginx/error.log（Nginx + PHP-FPM） - 确保
display_errors = Off（生产环境必须关），但log_errors = On和error_reporting = E_ALL必须开启 - 如果用的是 Nginx + PHP-FPM，还要检查
php-fpm.conf或 pool 配置里的slowlog和access.log，有时超时或段错误会写在那里
短链接还原常见触发 500 的 PHP 场景
还原逻辑本身简单，但几个典型坑会导致脚本中途崩溃：
- 数据库查询失败没做
try/catch或or die()判断，比如$stmt->execute()返回false后继续取fetch()，直接 fatal error - 使用了不兼容的函数，例如在低版本 PHP 里用了
str_starts_with()（PHP 8.0+），或curl_init()但cURL扩展未启用 - 短码解码后没校验长度或字符集，传入非法字符串给
base64_decode()或正则匹配，触发警告升级为错误（尤其当error_reporting包含E_WARNING且设置了zend.exception_ignore_args = Off时） - 重定向前已输出内容（比如开头多了一个空格、BOM 或
echo），导致header()失败并报 500（注意：此时错误日志里通常是「Cannot modify header information」）
临时调试：绕过 500 看真实错误信息
开发阶段可临时让错误显示出来，避免反复查日志：
立即学习“PHP免费学习笔记（深入）”；
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);
加在入口脚本最开头（如 index.php 第一行），但上线前必须删掉或设回 Off。另外，如果用的是现代路由框架（如 Slim、Laravel），要确认其错误处理器是否屏蔽了原始 PHP 错误——有时得关掉框架的 debug = false 或查看其 storage/logs/ 下的 stack trace。
还原接口部署后仍 500？重点检查这三处
很多问题不在 PHP 代码本身，而在运行上下文：
- Web 服务器权限：PHP 进程用户（如
www-data）是否对数据库 socket 文件、缓存目录、日志路径有读写权限？ls -l /var/run/mysqld/mysqld.sock看属主 - 短码参数丢失：Nginx 常见漏配
try_files $uri $uri/ /index.php?$query_string;，导致/abc123请求根本没进 PHP，被当成静态文件返回 404 或 500 - PHP-FPM 子进程崩溃：查看
systemctl status php*-fpm，若频繁 restart，可能是内存溢出或扩展冲突，tail -f /var/log/php*-fpm.log里会有segfault或child exited on signal
500 不是模糊错误，它背后一定有明确的 PHP 异常或系统级中断。日志路径、权限、路由转发，这三块没理清，光改代码只会反复踩进同一个坑。
