Nginx 不运行 Python，仅作反向代理；各项目须用独立虚拟环境启动 Gunicorn/Uvicorn 进程并监听不同端口，由 Nginx 按域名或路径分流，确保依赖隔离。
Nginx 本身不运行 Python，它只做反向代理和静态文件服务；真正隔离项目依赖靠的是后端 Python 应用进程（如 Gunicorn/Uvicorn）各自使用独立虚拟环境。关键不是 Nginx 配置环境，而是让每个项目启动时绑定自己的 venv 解释器和依赖。
每个项目配专属虚拟环境 + 独立应用进程
不能多个项目共用一个 Gunicorn 进程或一个 Python 解释器路径。必须为每个项目：
- 在项目根目录下创建独立虚拟环境，例如：python -m venv venv
- 激活后安装依赖：source venv/bin/activate && pip install -r requirements.txt
- 用该环境下的 Python 启动服务：例如 venv/bin/gunicorn --bind 127.0.0.1:8001 myapp:app
- 不同项目监听不同本地端口（如 8001、8002），由 Nginx 分流
Nginx 按域名或路径反向代理到对应端口
Nginx 不感知 Python 环境，只负责把请求转给正确的后端地址。例如：
- 项目 A（blog.example.com）→ 代理到 http://127.0.0.1:8001
- 项目 B（api.example.com）→ 代理到 http://127.0.0.1:8002
- 或同一域名下路径区分：example.com/admin/ → http://127.0.0.1:8003
这样，即使两个项目都用了 Flask，但一个装 Flask==2.0，另一个装 Flask==3.0，也完全互不影响。
立即学习“Python免费学习笔记（深入）”；
确保进程管理不混用解释器
用 systemd 或 supervisor 启动服务时，必须显式指定虚拟环境内的可执行文件：
- systemd 的 ExecStart= 要写全路径：/opt/myproject/venv/bin/gunicorn ...
- 不要写成 gunicorn（会调用系统全局命令）
- 检查进程实际使用的 Python：ps aux | grep gunicorn，再进进程查 readlink -f /proc/PID/exe 确认指向 venv 内的 python
部署时避免踩坑的硬性动作
不靠约定，靠验证：
- .venv 或 venv 目录绝不提交 Git，但 requirements.txt 必须提交
- 服务器上部署前先 source venv/bin/activate && pip list，确认只有预期包
- Nginx 配置里 proxy_pass 后的地址必须和 Gunicorn/Uvicorn 实际监听地址一致
- 日志中若出现 ModuleNotFoundError，优先检查是否启错了 venv 下的进程，而非 Nginx 配置
