必须用Gunicorn作WSGI中间层，因Nginx不解析Python代码且Flask/Django开发服务器无法满足生产要求；Gunicorn提供多进程管理、并发隔离、优雅重启与内存控制；Nginx通过proxy_pass反向代理至Gunicorn端口，并传递真实请求头；需配合systemd等工具守护进程，最终实现高可用Web服务。
直接用 Nginx 转发 Python Web 应用行不通，因为 Nginx 本身不解析 Python 代码，也不理解 Flask/Django 的应用逻辑。它需要一个中间层——Gunicorn 这类 WSGI 服务器，把你的 Python 应用“翻译”成标准 HTTP 接口，再由 Nginx 统一接收、分发和保护。
为什么必须加 Gunicorn 这一层
Nginx 是 HTTP 专家，但不是 Python 运行环境；Flask 或 Django 自带的开发服务器（如 flask run）只适合调试，没有进程管理、无并发隔离、不支持优雅重启、无法限制请求超时，一上生产就容易挂。
Gunicorn 正好补上这个缺口：它按 WSGI 规范启动多个独立 Python 进程（worker），每个进程加载一次你的应用（比如 app:create_app()），各自处理请求，互不干扰。模型类、全局变量、缓存实例都独享，避免线程竞争和内存泄漏。
- 单个 worker 崩溃，不影响其他 worker 继续服务
- 可设最大请求次数（
--max-requests），防内存缓慢增长 - 支持预加载（
--preload），让所有 worker 共享一份已初始化的模型或数据库连接池
Nginx 怎么把流量正确交给 Gunicorn
Nginx 不是直连 Python 文件，而是作为反向代理，把外部请求（比如访问 https://myapp.com/）转给本机某个端口上的 Gunicorn 实例（如 http://127.0.0.1:8000）。关键配置在 location / 块里：
立即学习“Python免费学习笔记（深入）”；
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
-
proxy_pass http://127.0.0.1:8000;—— 指定转发目标 -
proxy_set_header Host $host;和X-Real-IP $remote_addr;—— 把原始域名和真实 IP 传给 Gunicorn，否则 Flask 中request.host会变成127.0.0.1 -
proxy_buffering off;（对文件上传/流式响应建议关闭缓冲）
静态资源（CSS/JS/图片）建议由 Nginx 直接返回，不经过 Gunicorn，减少 Python 进程压力。
Gunicorn 启动方式要匹配部署场景
别再用 gunicorn app:app -b :8000 手动跑——这没守护、没日志、一断电就停。应配合进程管理工具（如 Supervisor 或 systemd）确保长期运行。
典型启动命令示例：
gunicorn --workers 4 --bind 127.0.0.1:8000 --timeout 120 --keep-alive 5 app:create_app-
--workers 4：CPU 核数 × 2 是常见起点，高 IO 场景可略增 -
--timeout 120：防长耗时请求（如图像超分、大文件导出）拖垮整个 worker -
app:create_app：对应 Flask 工厂函数写法；Django 则用myproject.wsgi:application
验证是否真正打通
三步快速确认链路正常：
- 本地
curl -v http://127.0.0.1:8000能拿到响应 → Gunicorn 已就位 -
curl -v http://localhost（Nginx 默认端口）能返回相同内容 → 反向代理生效 - 查
ps aux | grep gunicorn有多个 worker 进程，且netstat -tlnp | grep :8000显示监听中 → 进程未被意外终止
这时候，Python 应用才真正具备生产可用性：可抗并发、可限流、可扩缩、可监控、可平滑更新。
