flask 不能直接用 app.run() 上生产，因其使用单线程、无超时、不支持静态文件和负载均衡的 werkzeug 开发服务器，仅适用于开发；线上需用 gunicorn 等 wsgi 服务器配合 nginx 反向代理。
Flask 为什么不能直接用 app.run() 上生产
因为 app.run() 启动的是 Flask 自带的 Werkzeug 开发服务器，单线程、无超时控制、不处理静态文件、不支持负载均衡——它连基础并发都扛不住，更别说应对真实请求了。线上跑这个等于把门敞开让请求排队撞墙。
常见错误现象：WARNING: this is a development server. Do not use it in a production environment. 这不是提醒，是红牌警告。
- 开发服务器默认只监听
127.0.0.1:5000，外网根本连不上 - 一个请求卡住，整个进程就堵死；没有进程管理，崩溃后不会自动重启
- 不支持 http/2、gzip 压缩、连接复用等生产必需特性
Gunicorn 启动时怎么选 workers 和 worker-class
这两个参数直接决定吞吐和内存占用。选错会导致 CPU 空转或 OOM（内存溢出）。
workers 不是越多越好：推荐值是 2 * CPU核心数 + 1（比如 4 核机器设为 9）。超过这个数，python 的 GIL 会让额外 worker 白占内存、争锁，反而降低吞吐。
立即学习“Python免费学习笔记（深入）”；
worker-class 要按业务类型选：
- CPU 密集型（如图像处理、数值计算）：用默认的
sync就行 - IO 密集型（如调外部 API、数据库查询多）：换成
gevent或eventlet，但得额外装依赖且注意兼容性 - 混合型或不确定：先用
sync，压测后再调
示例启动命令：gunicorn -w 4 -b 127.0.0.1:8000 --timeout 30 --keep-alive 5 myapp:app
Nginx 怎么反向代理到 Gunicorn 并正确传头信息
只写 proxy_pass http://127.0.0.1:8000; 是不够的。Flask 需要原始 Host、协议、客户端 IP 才能生成正确 URL 和做日志，否则会出 Redirecting to https://localhost/login 这种问题。
必须显式透传关键头：
-
proxy_set_header Host $host;—— 不是$http_host，避免端口泄露 -
proxy_set_header X-Real-IP $remote_addr;—— 让 Flask 拿到真实 IP -
proxy_set_header X-forwarded-For $proxy_add_x_forwarded_for;—— 兼容多层代理 -
proxy_set_header X-Forwarded-Proto $scheme;—— 区分 http/https，否则url_for(..., _external=True)会错
还要关掉 Nginx 的缓冲：proxy_buffering off;，避免流式响应（如 SSE、大文件下载）被截断。
部署后发现 502 Bad gateway 或请求超时怎么办
90% 的 502 是 Gunicorn 没起来、端口没通、或被 Nginx 判定为不可用；超时则大概率是 Gunicorn --timeout 和 Nginx proxy_read_timeout 不一致。
排查顺序：
- 查 Gunicorn 日志：
ps aux | grep gunicorn看进程是否存在；netstat -tuln | grep :8000看端口是否监听 - 手动 curl Gunicorn：
curl -v http://127.0.0.1:8000/health，确认服务本身能响应 - 检查 Nginx 错误日志：
/var/log/nginx/Error.log，重点找connect() failed或upstream timed out - 两端 timeout 必须对齐：Gunicorn 的
--timeout 30对应 Nginx 的proxy_read_timeout 30;，不然 Nginx 先断连，Gunicorn 还在等
容易被忽略的一点：Gunicorn 默认只绑定 127.0.0.1，如果 Nginx 和 Gunicorn 不在同一台机器，得改成 -b 0.0.0.0:8000 并配好防火墙。