17370845950

真正需解决的是三类高频部署问题：一是gunicorn因运行用户环境不一致导致ModuleNotFoundError，应使用virtualenv并显式指定解释器路径；二是nginx 502因uWSGI socket通信失败，需检查socket路径、权限及uwsgi_read_timeout配置；三是celery任务丢失，因broker未持久化或启动参数缺失，须配置delivery_mode=2及--pidfile/--logfile。

这个标题本身不具备实操价值，不是问题、不是错误、也不是具体技术点。真正需要的不是“第511讲”这种编号式包装，而是你此刻卡在哪个环节：是 pip install 后模块找不到？gunicorn 启动报 Address already in use？还是 Flask 本地能跑，部署到 nginx + uWSGI 就 502？ 下面直奔三类高频真实场景：

为什么 import numpy 在 shell 里成功，但用 gunicorn 启动就报 ModuleNotFoundError

根本原因：运行用户环境不一致。你用 pip install numpy 是在当前用户（比如 ubuntu）的 Python 环境装的，而 gunicorn 可能以 www-data 用户启动，它压根没这个包。

• 先确认 gunicorn 实际用的 Python 路径：

  gunicorn --pythonpath /home/ubuntu/myapp --bind 0.0.0.0:8000 myapp:app

  中的 --pythonpath 必须指向含依赖的目录
• 更稳妥的做法：用 virtualenv 创建独立环境，并在启动命令中显式指定解释器：

  /opt/myapp/venv/bin/gunicorn --bind 0.0.0.0:8000 myapp:app

• 检查权限：确保 www-data（或你指定的运行用户）对 venv 目录有读+执行权限，chmod -R 755 /opt/myapp/venv

nginx 返回 502 Bad Gateway，但 uWSGI 日志里没报错

这通常不是代码问题，而是通信链路断了——nginx 找不到 uWSGI 进程，或者 socket 权限不对。

• 确认 uWSGI 是用 socket 模式启动的（不是 --http），且 socket 文件路径与 nginx 配置中 uwsgi_pass 一致，例如：

  uwsgi --socket /tmp/myapp.sock --chmod-socket=664 --chown-socket=www-data:www-data ...

• nginx 配置里必须加这一行：

  uwsgi_read_timeout 300;

  否则大响应或慢查询会直接触发 502
• 检查 socket 文件属主：ls -l /tmp/myapp.sock，必须是 www-data:www-data 或至少 www-data 有读写权

用 supervisor 管理 celery worker，重启后任务全丢

celery 本身不持久化任务状态，supervisor 只管进程生死。任务丢失，是因为 broker（比如 RabbitMQ 或 Redis）没配置消息持久化，或 celery 启动时没加关键参数。

• 启动命令必须带 --pidfile 和 --logfile，否则 supervisor 无法准确追踪进程：

  celery -A myapp.celery worker --loglevel=info --pidfile=/var/run/celery.pid --logfile=/var/log/celery.log

• 如果用 Redis 当 broker，确保 CELERY_BROKER_URL 包含 socket_keepalive=True 参数，避免连接空闲断开
• 任务入队时，显式设置 delivery_mode=2（持久化）：

  my_task.apply_async(args=[x], delivery_mode=2)

部署不是堆工具，是理清「谁以什么身份、在哪种环境下、用什么协议、和谁通信」。每个 502、每个 ModuleNotFoundError、每个静默退出，背后都是其中一环没对齐。别追教程编号，盯住你终端里那行红色错误字。