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