Gunicorn 和 Nginx 不是可选优化项，而是 Flask 上线的硬性门槛；Flask 自带开发服务器为单进程单线程调试工具，无超时控制与自动重启，无法处理并发或阻塞请求，而 Gunicorn 通过 pre-fork 模型实现多进程并行、超时熔断与内存泄漏防护，Nginx 则承担静态文件服务、请求过滤、HTTPS 终止及健康检查等核心网络职责，三者边界清晰、缺一不可。
gunicorn 和 nginx 不是“可选优化项”，而是 Flask 上线的硬性门槛。本地 flask run 一启动就弹出的 WARNING: This is a development server. Do not use it in a production deployment，不是提醒你“最好换”，而是明确告诉你：现在跑着的，根本就不是生产服务。
为什么 gunicorn 必须替代 flask run
Flask 自带服务器是单进程、单线程、无超时控制、无自动重启的调试工具，它连并发请求都扛不住——哪怕只是两个用户同时刷新页面，第二个请求就得排队等第一个返回；稍有阻塞（比如数据库慢查、外部 API 延迟），整个进程就卡死。
-
gunicorn默认用 pre-fork 模型，--workers 4就起 4 个独立 Python 进程，真正并行处理请求 - 每个 worker 有
--timeout 30（默认值），超时自动 kill + 重启，防住长连接拖垮服务 -
--max-requests 1000可强制 worker 处理千次请求后重启，缓解内存泄漏累积 - 它不解析 HTTP 协议，只专注执行你的
app对象，职责单一，故障面小
别写自定义 GunicornApplication 类——95% 的场景，直接命令行启动最稳：gunicorn --bind 127.0.0.1:8000 --workers 4 --timeout 30 app:app（注意最后是 app:app，前一个 app 是文件名，后一个 app 是 Flask 实例变量名）。
nginx 不是“转发器”，而是第一道防线
很多人把 nginx 当成简单反向代理：配个 proxy_pass http://127.0.0.1:8000 就完事。这会丢掉它 70% 的价值。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 静态文件必须由
nginx直接服务，location /static/ { alias /path/to/static/; }，绝不经gunicorn—— Python 进程读文件再吐 HTTP 响应，纯属浪费 CPU -
client_max_body_size 10M要设，否则大上传（如图片）直接被nginx拦在门外，gunicorn根本收不到请求 -
proxy_read_timeout 60必须 ≥gunicorn --timeout，否则nginx在gunicorn返回前就主动断连，用户看到 504 - 加
proxy_set_header X-Forwarded-For $remote_addr;，否则 Flask 里request.remote_addr永远是127.0.0.1
Ubuntu 系统级陷阱：权限、路径、systemd
在 Ubuntu 22.04（或 18.04/20.04）上，最容易栽在三件事上：
-
gunicorn启动时提示ImportError: cannot import name 'app'：多半是当前工作目录不对，cd到app.py所在目录再运行，或用--chdir /path/to/app -
nginx配置测试通过（sudo nginx -t），但sudo systemctl restart nginx失败：检查/etc/nginx/sites-enabled/下是否是软链接指向sites-available/，且目标文件权限为644，所有者为root - 服务开机不自启：别用
nohup或screen，写 systemd service 文件（/etc/systemd/system/myflask.service），关键行是User=www-data（非 root）和WorkingDirectory=/path/to/app
systemd 日志永远比 gunicorn 自己的日志更全：sudo journalctl -u myflask -f 能看到进程启动失败的真实原因（比如找不到 Python 模块、端口被占、venv 路径错）。
HTTPS 和健康检查不能靠“先上线再补”
上线当天才配 HTTPS？等于裸奔。Let’s Encrypt 的 certbot 必须在 nginx 配置里预留 /.well-known/acme-challenge/ 路径，并确保该路径不走 proxy_pass；否则证书申请必失败。
- 加
location /healthz { return 200 'OK'; }到nginx配置里，供负载均衡器或云平台做存活探测 - Flask 里别写
@app.route('/healthz')——健康检查必须绕过应用逻辑，由nginx直答，避免因应用卡死导致误判 -
gunicorn的--preload参数慎用：它会让所有 worker 共享同一份初始化代码，若含全局状态（如未加锁的计数器），可能引发数据污染
真正的难点不在配置语法，而在分清边界：Flask 只管业务逻辑，gunicorn 只管进程生命周期，nginx 只管网络流量。哪一层越界做事，哪一层就容易出不可复现的问题。
