Gunicorn 提示 Worker timeout 通常是因为工作进程处理请求或启动时间超过了默认限制，最直接的处理方法是临时调大超时参数并排查阻塞代码。
先说结论：该错误意味着 Gunicorn 主进程未收到工作进程的 heartbeat，需优先区分是启动慢还是请求处理慢。
- 先确认：查看日志确定是启动阶段超时还是请求处理阶段超时
- 先处理：临时增加 `--timeout` 参数止血，同时排查数据库或外部 API 阻塞
- 再验证：观察日志不再出现 SIGTERM 或 timeout 报错且请求响应正常
命令速用版
在启动命令中显式指定超时秒数，例如将默认 30 秒调整为 60 秒：
gunicorn `--timeout` 60 myproject.wsgi:application若使用配置文件，可在 gunicorn.conf.py 中设置 timeout = 60。
为什么会这样
Gunicorn 主进程（Arbiter）会定期检查工作进程（Worker）的状态，若超过设定时间未收到信号则判定为超时。
默认超时时间为 30 秒，若 Django 视图中有耗时操作、数据库锁等待或初始化代码过重，工作进程无法在规定时间内完成心跳汇报，主进程会强制杀死该工作进程并记录 Worker timeout 错误。
分步处理
第一步：检查日志定位阶段
查看 Gunicorn 错误日志，确认报错发生在请求期间还是服务启动期间。若是启动期间，检查 Django app ready 方法或导入模块是否有耗时操作。
第二步：临时调整超时参数
通过命令行参数 `--timeout` 或配置文件调大数值，确保服务能暂时稳定运行，避免频繁重启影响业务。
第三步：排查阻塞代码
检查耗时请求对应的视图函数，确认是否存在同步调用外部 API、复杂数据库查询或未优化的循环操作。必要时将耗时任务移至 Celery 等异步队列。
第四步：检查系统资源
确认服务器 CPU 和内存是否充足，资源争抢可能导致进程调度延迟从而触发超时。
怎么验证是否生效
观察 Gunicorn 日志文件，确认不再出现 Worker timeout 或 SIGTERM 相关报错。
使用 curl 或浏览器访问触发超时的接口，确认请求能在设定时间内返回 200 状态码且无明显卡顿。
常见坑
不要长期依赖调大超时参数掩盖性能问题，过高的超时值会导致请求堆积。
Django 开发模式下的 autoreload 机制可能与 Gunicorn 冲突，生产环境务必关闭 DEBUG 模式。
若使用 Gevent 等异步 Worker，超时逻辑可能与同步 Worker 不同，需参考对应文档。
常见问题
超时参数设置多大合适？
通常建议保持在 30 秒至 60 秒之间，超过 60 秒往往意味着代码需要优化而非调整配置。
Worker timeout 和 502 Bad Gateway 有关系吗？
有关系，Gunicorn 杀死超时进程后，若 Nginx 反向代理连接不上新进程，会返回 502 错误。
调整超时会影响已有连接吗？
调整配置重启服务会影响现有连接，热重载配置通常不直接支持超时参数动态变更。
参考来源
- Gunicorn Official Documentation, Settings - timeout, https://docs.gunicorn.org/en/stable/settings.html#timeout