真实错误一定写在php错误日志里，而非浏览器500页面；需用php -i | grep error_log定位准确路径，检查权限（如/www/wwwlogs/属主应为www:www），并确保php.ini中log_errors=on、error_reporting=e_all生效，改后重启php-fpm。
直接看 PHP 错误日志，别信浏览器空白页
500 错误本身不带任何有效信息，浏览器只显示“Internal Server Error”，是因为 PHP 在执行中触发了 E_ERROR、E_PARSE 或未捕获的异常，但 display_errors 被关了，错误被吞掉，只留下 HTTP 状态码 500。真实错误一定写在日志里，而不是页面上。
关键动作是立刻定位并读取 PHP 自己的错误日志，不是 Apache/Nginx 的 error.log（那里面可能只有“PHP message: …”这种模糊转发）。
- 运行
php -i | grep error_log，看输出的error_log值——这是最准的，它反映当前生效的配置 - 如果返回为空或
no value，说明log_errors = Off或没设error_log路径，需手动补全 - 小皮/宝塔等面板用户特别注意：
/www/wwwlogs/php_error.log常因权限问题写不进内容，用ls -l /www/wwwlogs/看属组是否为www:www，否则日志静默失效
临时强制暴露错误：ini_set 不总管用，得改 php.ini
ini_set('display_errors', '1') 和 error_reporting(E_ALL) 放在脚本开头，对语法错误（比如少括号、Parse error）完全无效——因为解析阶段就失败了，代码根本没机会执行到那一行。
真正能捕获全部错误的方式，是修改 PHP 运行时配置：
- 找到真实生效的
php.ini：运行php --ini，关注 “Loaded Configuration File” 行 - 编辑该文件，确保这三项同时启用：
display_errors = On、log_errors = On、error_reporting = E_ALL - 改完必须重启 PHP-FPM（不是仅 reload）：如
systemctl restart php-fpm或面板里点“重启PHP” - 注意：生产环境切勿长期开启
display_errors，仅用于紧急定位
常见伪“500”陷阱：.htaccess、扩展缺失、权限错位
有些 500 根本不是 PHP 代码问题，而是 Web 服务器层拦截导致的假性致命错误。
-
.htaccess语法错误（比如用了Header但mod_headers没启用），Apache 直接拒载整个目录，报 500 —— 临时重命名.htaccess为.htaccess.bak测试是否恢复 - PHP 扩展缺失（如项目 require
Redis，但extension=redis.so没加载），错误日志里会出现Class 'Redis' not found或undefined function redis_connect() - Linux 权限错位：PHP-FPM 以
www用户运行，但代码文件属主是root且权限为600，连读都做不到，直接 500 —— 执行chown -R www:www /path/to/project和chmod -R 755 /path/to/project
用 php -l 快速筛出语法错误
当怀疑是某几个 PHP 文件导致问题时，别靠刷新页面试，用 CLI 直接检测语法：
- 运行
php -l index.php，返回No syntax errors detected就通过；否则会明确指出第几行、什么错误（如Parse error: syntax error, unexpected '}'） - 批量检查：用
find /path/to/app -name "*.php" -exec php -l {} \;，跳过所有无语法问题的文件，只报错有问题的 - 注意：
php -l不执行代码，所以不会触发require失败、数据库连接超时这类运行时错误，但它能秒杀 80% 的硬编码失误
error_log 路径权限为 root:root，或者忘了小皮里每个站点可单独配 .user.ini 覆盖全局 php.ini，结果改了半天主配置却不起作用。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
