flask自带的flask run不能用于生产，因其单线程、无连接池、不抗并发、不处理ssl、一卡全卡；必须用gunicorn作wsgi容器、nginx作反向代理，构成生产部署事实标准链路。
Flask 自带的 flask run 不能上生产，不是“不够好”，而是根本没设计成干这事——它单线程、无连接池、不抗并发、不处理 SSL、一卡全卡。真要对外提供服务，必须用 Gunicorn 做 WSGI 容器 + Nginx 做反向代理，这是当前 Python Web 生产部署的事实标准链路。
为什么不能直接用 gunicorn --bind :5000 启动后让 Nginx 反代到 5000 端口？
能跑通，但不安全、不高效、不健壮。关键问题在连接模型和资源暴露：
-
gunicorn --bind :5000把端口直接暴露在公网或内网，绕过了 Nginx 的连接复用、请求队列、TLS 终结和限流能力 - HTTP 长连接、Keep-Alive、Chunked Transfer 编码等行为在 TCP 层直连时容易出错，尤其当 Flask 返回流式响应（如 SSE 或大文件下载）时，
proxy_buffering on默认会缓存整个响应体，导致前端卡住 - Ubuntu 22.04 上 systemd 默认限制每个服务的文件描述符数（
LimitNOFILE），若 Gunicorn 直接监听端口，需额外配置；而用 Unix socket 则由 Nginx 控制连接生命周期，更可控 - 实际线上故障里，约 30% 的 502 Bad Gateway 来自 Nginx 和 Gunicorn 之间协议不匹配，比如
proxy_http_version 1.1没开、proxy_set_header Connection ''漏设
gunicorn 启动命令里 --workers 和 --threads 怎么配？
别拍脑袋。worker 数量直接影响内存占用和并发吞吐，配错轻则浪费资源，重则 OOM 被系统 kill：
- 同步 worker（默认）：建议设为
CPU 核心数 × 2 + 1，Ubuntu 22.04 上可用nproc查看；超过 8 个通常收益递减 - 如果 Flask 应用大量调用慢 IO（如 requests.get、数据库查询），可加
--threads 2-4，但注意 CPython 的 GIL 会让纯 CPU 密集型任务无效 - 绝对不要用
--reload上生产——它依赖文件系统 inotify，会吃光 inode，且热重载时旧进程可能残留，造成内存泄漏 - 务必加
--timeout 120（默认 30 秒太短），避免数据库慢查询拖垮整个 worker；同时配--graceful-timeout 30，确保 SIGTERM 有足够时间优雅退出
nginx 配置里最常漏掉的三行 header 是什么？
这三行不加，Flask 的 request.remote_addr 会变成 127.0.0.1，日志、限流、IP 白名单全失效：
location / {
include proxy_params;
proxy_pass http://unix:/path/to/myapp.sock;
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;
}
其中 X-Forwarded-For 必须用 $proxy_add_x_forwarded_for（不是 $remote_addr），否则多层代理时 IP 链会断；X-Forwarded-Proto 决定 Flask 的 url_for(..., _external=True) 生成 http 还是 https 链接。
systemd 服务文件里 RestartSec=10 比 Restart=always 更安全？
是的。Gunicorn 崩溃后立刻重启，可能触发雪崩式失败：
-
Restart=always不管崩溃原因，秒级重试，若因数据库连不上或磁盘满导致启动失败，会反复 fork 进程，快速耗尽内存或 ulimit -
RestartSec=10强制间隔 10 秒，给下游依赖（如 PostgreSQL、Redis）恢复时间；配合StartLimitIntervalSec=60和StartLimitBurst=3，60 秒内只允许启动 3 次，超限就 stop 并报警 - Ubuntu 22.04 的
/etc/systemd/system/myapp.service中，User=www-data必须与 Nginx 的user配置一致，否则 socket 文件权限拒绝访问，报错connect() to unix:/path/to/app.sock failed (13: Permission denied)
真正难的不是写对第一行配置，而是理解每行背后的 OS 层约束、网络栈行为和 Python 运行时特性。比如 proxy_buffering off 对流式响应必要，但关了它又可能让 Nginx 在高并发下吃光内存——这种权衡没法靠教程列表解决，得看 journalctl -u myapp -n 100 和 curl -v http://localhost/health 的实际响应头。
