Worker启动失败时应加--log-level debug和--error-logfile -强制输出完整错误链路，重点检查导入路径、Python解释器环境、workers数量及ulimit限制，推荐用--chdir指定项目根目录确保模块可导入。
Worker启动失败时怎么看日志
Gunicorn worker退出不报错，是部署中最让人抓狂的情况。默认它把错误吞掉，只留一句 Worker failed to boot。必须强制让它输出完整错误链路：
- 加
--log-level debug启动，让 Gunicorn 把 import 阶段的异常也打出来 - 加
--error-logfile -把错误日志直接输出到终端（不是文件），避免写入权限问题导致日志丢失 - 别依赖
systemctl status gunicorn—— 它只显示主进程状态，worker 崩溃后可能只剩 master 在空转
典型命令：gunicorn --log-level debug --error-logfile - --bind 127.0.0.1:8000 myproject.wsgi:application
Worker卡在“import django”阶段的真正原因
日志里出现 ModuleNotFoundError: No module named 'django' 或类似 ImportError: No module named 'myproject.wsgi'，不是 Django 没装，而是 Python 解释器根本没找到你的代码路径。
-
gunicorn默认用当前 shell 的PYTHONPATH和sys.path，不会自动把项目根目录加进去 - 如果你的
wsgi.py在/home/user/myproject/myproject/wsgi.py，但启动时不在/home/user/myproject目录下，myproject.wsgi就会导入失败 - 虚拟环境激活了，但
gunicorn被系统级 pip 安装过，调用的是系统 Python，而不是 venv 里的解释器
验证方式：which gunicorn 看路径；再执行 venv/bin/gunicorn --version 对比版本和路径是否一致
workers数量设多反而启动不了
设 --workers 8 看起来很“生产”，但实际常导致内存不足或数据库连接耗尽，尤其在小内存 VPS 上。
- Django 默认数据库连接池是每 worker 一个连接，8 个 worker 就占 8 个连接，超出
max_connections时，worker 初始化就卡死在 DB 连接上 - Linux 默认
ulimit -n（文件描述符数）常为 1024，每个 worker 占几十个 fd，超限后新 worker 无法创建 socket - 推荐值：单核机器用
--workers 2；双核起用--workers 3；超过 4 个需同步调大ulimit -n和数据库连接上限
临时调高限制：ulimit -n 65536，再启动 Gunicorn
为什么用 --pythonpath 还是找不到模块
--pythonpath 参数看似能补路径，但它只影响 sys.path，不解决包结构合法性问题。
- 如果项目目录名含破折号（如
my-django-app），Python 不允许用my-django-app.wsgi导入 —— 破折号不是合法标识符 - 如果
wsgi.py所在目录没有__init__.py，即使加了--pythonpath，Python 也不会把它当包处理 -
--chdir /path/to/project比--pythonpath更可靠：它先 cd 进去再执行，等效于人工cd+gunicorn ...
安全启动命令：gunicorn --chdir /home/user/myproject --bind 127.0.0.1:8000 myproject.wsgi:application
最容易被忽略的一点：Gunicorn 启动时检查的是 sys.path[0]，也就是当前工作目录。哪怕你 pip install -e . 了项目，只要没 --chdir 或没在正确位置运行，myproject.wsgi 就永远是个谜。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
