Flask项目绝不能用flask run上生产，必须采用uWSGI+Nginx组合部署；前者单进程、无超时、不支持请求队列，高并发下极易崩溃，后者通过进程管理、内存监控、异步支持与反向代理、超时控制、连接复用协同保障稳定高性能。
Flask 项目绝不能用 flask run 上生产 —— 它单进程、无超时、不排队，三五个并发就卡死或崩溃。真正可用的部署必须是 uWSGI + Nginx 组合，且二者配置不是填参数就行，得按业务类型（CPU/I/O/内存敏感）和机器资源动态调优。
为什么必须禁用 flask run，改用 uWSGI
flask run 是纯开发服务器，没进程管理、没内存监控、不支持异步、无法优雅重启。线上一出错整个进程就挂，连日志都来不及刷。而 uWSGI 是容器级应用服务器，能干这些事：
-
--processes和--threads可拆分 CPU 密集型负载（比如图像处理），避免 GIL 拖累 -
--plugin=gevent+--gevent 100能直接跑 I/O 密集型服务（如调外部 API、慢 SQL），不用改代码 -
--reload-on-rss 512对加载大模型或长驻缓存的服务至关重要，RSS 超 512MB 自动 reload，防 OOM 僵死 - 漏配
--reload-on-rss是常见坑：日志里反复出现worker N killed due to memory usage，但进程不重启，请求持续失败
uWSGI 配置里最易错的 4 个参数
写 .ini 文件时，以下几项不设对，轻则 502，重则服务不可达：
-
socket = /tmp/myapp.sock：必须用 Unix socket（而非127.0.0.1:8001），Nginx 访问更快更安全；同时配chmod-socket = 660和chown-socket = www-data:www-data -
callable = app：必须显式声明 Flask 实例变量名；如果代码里写的是application = Flask(...)却没写这行，uWSGI启动就报ImportError: no module named 'app' -
master = true+vacuum = true：缺一不可。前者启用主控进程，后者确保退出时自动清理 socket 文件，否则下次启动报Address already in use -
die-on-term = true：让systemd或supervisor发SIGTERM时能干净退出，不然 kill 不掉残留 worker
Nginx 反向代理必须加的 3 条保命配置
Nginx 在这里不是“转发器”，而是第一道缓冲和熔断阀。默认配置下它会把客户端 Connection: close 直接透传给 uWSGI，导致连接无法复用；更危险的是不设超时，uWSGI 还在跑慢请求，Nginx 先返回 504 Gateway Timeout。
立即学习“Python免费学习笔记（深入）”；
-
proxy_read_timeout 300：必须 ≥ uWSGI 的harakiri值（比如你设了harakiri = 240，这里就得 ≥ 240），否则 Nginx 先断 -
proxy_buffering off：对流式响应（如 SSE、大文件下载）必须关缓冲，否则卡住不吐数据 -
upstream块里加keepalive 32：复用到 uWSGI 的连接，否则每个请求新建 TCP，短连接压测时直接打满 TIME_WAIT
启动后 502 错误最可能的 3 个原因
看到 502 Bad Gateway 别急着改 Nginx，先查这三项：
-
uWSGI进程根本没起来：运行ps aux | grep uwsgi，空则说明配置语法错或权限不足（比如 socket 路径父目录不可写） -
socket文件权限不对：ls -l /tmp/myapp.sock看属组是否为www-data，不是就chown www-data:www-data /tmp/myapp.sock -
Nginx没读到 upstream：检查nginx.conf是否include /etc/nginx/conf.d/*.conf，且你的server块里uwsgi_pass指向的地址和uWSGI的socket完全一致（路径 or IP:port）
复杂点不在组件多，而在参数之间有强依赖：比如 harakiri 和 proxy_read_timeout 必须梯度匹配，reload-on-rss 和机器总内存要留余量。一个参数调错，整条链路就卡在你看不见的地方。
