500错误主因是Laravel初始化失败：bootstrap/cache/config.php残留旧配置或APP_KEY未生成，导致config:cache中断；需先rm -f bootstrap/cache/*.php，再确认APP_KEY存在并执行key:generate，最后成功运行config:cache。
500 错误不是代码崩了，而是 Laravel 还没跑起来就卡在初始化阶段——最常见原因是 bootstrap/cache/config.php 里塞着旧环境的配置，或者 APP_KEY 根本没生成。
config:cache 失败导致框架启动中断
迁移后执行 php artisan config:cache 报错或静默失败，是 500 的头号诱因。这个命令会把 .env 和 config/ 下所有文件编译成单个 PHP 文件（bootstrap/cache/config.php），一旦里面残留旧数据库密码、缓存驱动或调试开关，Laravel 就会在服务容器构建前直接 die()，且不写日志。
- 先删光缓存：
rm -f bootstrap/cache/*.php（别只信config:clear） - 确认
.env里APP_KEY存在且非空：grep APP_KEY .env；若为空，立刻运行php artisan key:generate --force - 再执行
php artisan config:cache——这步必须成功，否则后续全白搭 - 注意：如果用的是 PostgreSQL，
DB_CONNECTION=pgsql但没装pdo_pgsql扩展，也会在这里挂掉，php -m | grep pgsql看一眼
storage 和 bootstrap/cache 权限不对
Linux 服务器上，Web 用户（如 www-data 或 nginx）没权限读写 storage 和 bootstrap/cache，会导致日志写不进 storage/logs/laravel.log、视图缓存无法生成、Session 存不了——表面是 500，实际是权限拒绝。
- 给目录设权限：
chmod -R 775 storage bootstrap/cache - 改属组（关键）：
chown -R $USER:www storage bootstrap/cache（www替换为你的 Web 组名，宝塔常用www，Ubuntu 常用www-data） - 别用
777，Nginx 会拒绝加载 world-writable 的配置文件
APP_DEBUG=false 时错误完全不可见
生产环境设了 APP_DEBUG=false，又没配好日志驱动（比如误设成 stack 但没定义 channels），结果错误既不显示也不落盘，只剩一个干巴巴的 500。
- 临时打开调试：
APP_DEBUG=true，然后php artisan config:cache再试一次，看页面是否吐出真实报错 - 检查
config/logging.php中default对应的 channel 是否可用，比如single驱动依赖storage/logs可写 - 如果 Nginx error_log 也空，说明错误发生在 PHP-FPM 层之前，重点查
php.ini的display_errors = Off和log_errors = On
PostgreSQL 迁移后 config.php 残留旧连接参数
从 MySQL 迁到 PostgreSQL 后，即使改了 .env，bootstrap/cache/config.php 仍可能带着 "driver": "mysql" 和旧的 host/port，导致 DB::connection() 初始化失败，框架直接退出。
- 不要手动编辑
config.php，它会被下次config:cache覆盖 - 执行前务必确认
.env中DB_CONNECTION=pgsql、DB_PORT=5432、DB_DATABASE等全部正确 - 如果用的是 pg_restore 导入数据，记得同步创建用户并赋权：
CREATE USER myapp WITH PASSWORD 'xxx'; GRANT ALL PRIVILEGES ON DATABASE myapp TO myapp;
真正难搞的从来不是报错内容，而是错误根本没发生——因为权限或缓存挡在了日志系统前面。每次部署后第一件事，不是测功能，是看 storage/logs/laravel.log 能不能写进去一行时间戳。
