Python部署成败取决于对venv、pip、gunicorn、systemd等组件协作关系的理解，而非虚构的“第231讲”编号；关键在环境隔离、依赖管理、gunicorn配置与systemd服务定义的精准实践。

Python部署系统没有标准“第231讲”这种课程编号，它不是官方体系里的固定章节，而是某些培训机构或自媒体为制造学习节奏感虚构的序号。真正决定部署成败的，从来不是讲数，而是对 venv、pip、gunicorn、systemd 这些组件间协作关系的理解深度。

为什么用 venv 而不是全局 pip install

全局安装会污染系统 Python 环境，不同项目依赖同一包但版本冲突时（比如项目 A 需要 requests==2.25.1，项目 B 需要 requests==2.31.0），直接报错或行为异常。生产环境一旦出问题，排查成本远高于初始化成本。

• 始终在项目根目录执行 python -m venv .venv 创建隔离环境
• 激活后务必确认 which python 和 which pip 指向 .venv/bin/python 路径
• requirements.txt 必须用 pip freeze > requirements.txt 生成，不能手写——否则缺失间接依赖（如 urllib3 被 requests 依赖但未显式声明）

gunicorn 启动 Web 服务时常见崩溃原因

本地 flask run 能跑，上线用 gunicorn 就 502 或直接退出，大概率是工作进程启动失败，而非代码逻辑错误。

• 检查入口模块路径是否正确：gunicorn --bind :8000 myapp:app 中的 myapp 是 Python 模块名（对应 myapp.py 文件），不是文件路径
• 确保 app 对象在模块顶层可访问，不要藏在 if __name__ == "__main__": 里
• 日志必须打开：gunicorn --access-logfile - --error-logfile - myapp:app，否则 silent crash 无迹可寻
• 内存不足时 gunicorn 会杀掉 worker，需配合 --max-requests 1000 --max-requests-jitter 100 主动轮换

用 systemd 管理 Python 服务时最常漏的三件事

systemd 不是启动脚本封装器，它按自身规则管理生命周期。漏掉任意一项，都会导致服务无法自启、挂了不拉起、或日志全丢。

• WorkingDirectory 必须显式设置，否则 gunicorn 找不到 requirements.txt 或静态文件
• Environment="PATH=/opt/myapp/.venv/bin:/usr/bin" —— 不设 PATH，systemd 默认不用 shell，找不到 python 或 gunicorn
• Type=notify 或 Type=simple 必须匹配：若用 --preload 或 gunicorn 的 --daemon，得选 Type=simple；若用 --preload + --workers 1 并配合 gunicorn 的 systemd 集成，则用 Type=notify

[Unit]
Description=My Flask App
After=network.target
[Service]
Type=simple
User=www-data
WorkingDirectory=/opt/myapp
Environment="PATH=/opt/myapp/.venv/bin:/usr/bin"
ExecStart=/opt/myapp/.venv/bin/gunicorn --bind unix:/run/myapp.sock --workers 2 myapp:app
[Install]
WantedBy=multi-user.target

部署最难的部分，往往不是某个命令不会敲，而是不知道该查哪条日志、该看哪个进程状态、该怀疑哪一层配置。比如 systemctl status myapp 显示 active (running)，但 curl 502，这时候第一反应不该是重装 gunicorn，而应立刻 sudo journalctl -u myapp -n 50 看真实错误输出——很多超时、权限、路径问题，只在 journal 里留痕。