500错误是服务端进程崩溃导致HTTP响应失败，需优先检查Nginx/Apache错误日志、应用日志及权限问题，而非前端操作；PHP语法错误、Node.js未捕获Promise拒绝、Python导入失败等均会触发该错误。
500 错误不是前端问题，别在浏览器里瞎按 F5
HTTP 500 是服务器明确告诉你“我崩了”，和网络、缓存、JS 报错完全无关。前端刷新页面、清 localStorage、换浏览器，全无效。必须查服务端日志，否则永远在原地打转。
常见错误现象：500 Internal Server Error 出现在浏览器控制台 Network 标签页的响应状态栏；curl 请求返回空响应体或 curl: (52) Empty reply from server；Nginx 日志里出现 upstream prematurely closed connection —— 这说明后端进程已挂，连 HTTP 响应头都没发出来。
- 先看 Web 服务器错误日志：Nginx 查
/var/log/nginx/error.log，Apache 查ErrorLog指向的路径 - 再查应用日志：PHP-FPM 对应
slowlog和error_log；Node.js 看进程 stdout/stderr 或 pm2 logs；Python Django/Flask 通常输出到gunicorn.error.log或 systemd journal - 如果日志为空？检查是否禁用了错误输出（如 PHP 的
display_errors = Off）或日志级别设得太高（如只记ERROR，但实际是WARNING导致的崩溃）
PHP 里 parse_error 和 Fatal error 都会触发 500
PHP 脚本一启动就语法错误（比如少个 ;、function 拼错成 funtion），或运行中遇到未定义函数、内存超限、递归爆栈，都会让 PHP-FPM worker 进程退出，Nginx 就只能回 500。
典型表现：请求瞬间返回 500，无响应体；PHP-FPM 错误日志里有类似 PHP Parse error: syntax error, unexpected '}' 或 PHP Fatal error: Allowed memory size of 134217728 bytes exhausted 的记录。
立即学习“前端免费学习笔记（深入）”；
- 用
php -l your_script.php检查单个文件语法，比等 Nginx 报错快得多 - 临时开启 PHP 错误显示：在入口脚本开头加
ini_set('display_errors', '1'); error_reporting(E_ALL);（仅限开发环境） - 内存不足？检查
memory_limit设置，但更关键的是看有没有死循环或大数组未释放（比如$data = file_get_contents('huge.json')后没 unset）
Node.js 中未捕获的 Promise rejection 默认不报错，但会杀进程
Node.js 15+ 默认把未处理的 Promise rejection 当作致命错误，直接退出进程 —— 这时反向代理（如 Nginx）收不到任何响应，就返回 500。它不像同步错误那样立刻抛出堆栈，所以特别隐蔽。
常见场景：数据库查询失败没写 .catch()，async 路由里 await fs.readFile() 报错后没兜底，或者 process.on('unhandledRejection') 被删了。
- 务必在应用启动时监听：
process.on('unhandledRejection', (err) => { console.error(err); process.exit(1); }); - 用
pm2 start app.js --no-autorestart启动，避免崩溃后自动拉起掩盖问题 - 检查
console.error是否被重定向或丢弃；systemd 管理的服务要确认StandardError=journal并用journalctl -u your-app -n 50查实时日志
Python WSGI 应用启动失败，Gunicorn 只报 Worker failed to boot
Gunicorn 启动时加载应用模块失败（比如 ImportError、ModuleNotFoundError、AttributeError），就会卡在 worker 初始化阶段，Nginx 连接 upstream 超时，最终返回 500。但 Gunicorn 自己的日志可能只写一句 Worker failed to boot.，根本没说哪行错了。
典型原因：requirements.txt 没装全（比如漏了 psycopg2 导致 Django 连 PostgreSQL 失败）；相对路径导入出错（from ..utils import helper 在非包上下文运行）；环境变量缺失导致 os.environ['SECRET_KEY'] 报 KeyError。
- 手动模拟启动：运行
gunicorn --bind "127.0.0.1:8000" --workers=1 --log-level debug myapp.wsgi:application，看完整 traceback - 检查 Python 路径：
gunicorn启动目录是否和manage.py一致？sys.path里有没有漏掉项目根目录？ - 用
python -c "import myapp.wsgi; print('ok')"快速验证模块能否成功 import
www-data）没权限写入日志目录，导致错误静默丢失。先 ls -l /var/log/your-app/ 看属主，再 sudo -u www-data touch /var/log/your-app/test.log 试写一次。 
