Flask应用不可用flask run上生产，必须采用uWSGI+Nginx组合部署；uWSGI提供进程管理、内存监控与异步支持，Nginx承担反向代理、超时控制与连接复用，二者参数须按业务类型（CPU/I/O密集、内存敏感）及硬件资源协同调优，尤其harakiri与proxy_read_timeout需梯度配置。
直接用 flask run 启动的 Flask 应用绝不能上生产 —— 它单进程、无超时控制、不支持请求队列，高并发下几秒就挂。真正能扛住流量的部署，必须是 uWSGI + Nginx 组合，且配置项不是照搬模板就能生效，很多参数要根据你的应用类型（CPU 密集 or I/O 密集）、机器核数、内存大小动态调整。
为什么 uWSGI 比 Gunicorn 更适合复杂 Flask 服务
uWSGI 不只是“另一个 WSGI 服务器”，它本质是一个应用容器平台：自带进程管理、信号控制、内存监控、插件系统。对模型推理类 Flask 服务（比如集成 Sambert-Hifigan 的 TTS 接口），它的 --max-requests 和 --reload-on-rss 能有效缓解内存泄漏；对需长连接或 WebSocket 的场景，gevent 或 eventlet 插件可直接启用异步模式，而 Gunicorn 需额外装扩展且稳定性略差。
常见错误现象：uWSGI 启动后日志里反复出现 worker N killed due to memory usage，但没配 --reload-on-rss，导致 OOM 后进程僵死不重启。
- CPU 密集型服务（如图像处理）：用
--processes+--threads 1，避免 GIL 竞争 - I/O 密集型服务（如调用外部 API、数据库慢查询）：启用
--plugin=gevent，配合--gevent 100 - 内存敏感服务（如加载大模型）：必须设
--reload-on-rss 512（单位 MB），防止 RSS 持续增长 - 所有生产配置必须禁用
--honour-stdin和--master-fifo这类调试开关
Nginx 反向代理必须加的关键配置项
Nginx 在这里不只是转发请求，更是第一道缓冲和熔断阀。默认配置下，它会把客户端的 Connection: close 直接透传给 uWSGI，导致连接无法复用；更严重的是，若不设 proxy_read_timeout，uWSGI 处理慢请求时 Nginx 会先超时断开，返回 504 Gateway Timeout，而 uWSGI 其实还在跑。
典型遗漏配置：
upstream flask_app {
server 127.0.0.1:8001;
keepalive 32; # 必须设，否则每个请求新建 TCP 连接
}
<p>server {
listen 80;
location / {
proxy_pass <a href="https://www.php.cn/link/648cbc29675eff7e6f337ffc66c907de">https://www.php.cn/link/648cbc29675eff7e6f337ffc66c907de</a>;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;</p><pre class="brush:python;toolbar:false;"> proxy_connect_timeout 5;
proxy_send_timeout 30;
proxy_read_timeout 60; # 关键！要比 uWSGI 的 --harakiri 大 10s
proxy_buffering on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
}
}
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
注意：proxy_read_timeout 必须大于 uWSGI 的 --harakiri 值（默认 30s），否则 Nginx 先杀连接，uWSGI 日志里却看不到超时记录，排查极难。
uWSGI 启动命令与配置文件的取舍
命令行启动适合调试，但生产环境必须用 INI 配置文件 —— 因为 --stats、--memory-report、--log-maxsize 等关键运维参数无法通过命令行稳定传递，且容易被 shell 转义破坏。
一个最小可用的 uwsgi.ini 示例：
[uwsgi] module = wsgi:app master = true processes = 4 threads = 2 socket = 127.0.0.1:8001 chmod-socket = 660 vacuum = true die-on-term = true harakiri = 30 max-requests = 1000 reload-on-rss = 512 logto = /var/log/uwsgi/flask.log log-maxsize = 10000000 stats = 127.0.0.1:9191
容易踩的坑：
-
module = wsgi:app中的wsgi是文件名（不含 .py），app是变量名 —— 若你用工厂函数，得写成module = wsgi:create_app('production') -
vacuum = true必须开启，否则 worker 退出后 socket 文件残留，下次启动报Address already in use -
die-on-term = true让 uWSGI 响应 systemd 的 SIGTERM，否则systemctl stop会卡住 -
stats端口要单独用 Nginx 反代暴露（如/uwsgi-stats），别直接监听 0.0.0.0
最常被忽略的一点：uWSGI 的 --harakiri 和 Nginx 的 proxy_read_timeout 必须形成梯度关系，且两者都要比你的最长业务逻辑耗时多出至少 10 秒 —— 否则你永远在查“为什么请求明明没超时，却收不到响应”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
