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 集成，则用T
ype=notify
ype=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 里留痕。
