Python生产环境升级需多版本共存与平滑切换，核心是老进程不杀、新代码能跑、流量不丢；必须用pyenv或编译安装至隔离路径，显式指定解释器全路径，确保libpython动态链接正确，并通过ensurepip和pip完整初始化生态。
Python 升级时服务不能中断，得用多版本共存 + 平滑切换
生产环境升级 Python 版本，核心不是“怎么装新版本”，而是“老进程不杀、新代码能跑、流量不丢”。直接 apt install python3.11 或重装系统 Python 会触发依赖冲突、systemd 重启失败、甚至 gunicorn 工作进程集体退出——这不是升级，是抖动。
可行路径只有一条：让新旧 Python 解释器并存，应用层控制启动入口，再靠进程管理器逐个热替换。
- 必须用
pyenv或编译安装到/opt/python-3.11.9这类隔离路径，绝不能覆盖/usr/bin/python3 -
pip必须跟解释器绑定：用/opt/python-3.11.9/bin/python -m pip install -r requirements.txt，别信python3.11 -m pip—— 系统 PATH 里可能根本没这个命令 - 所有启动脚本（
gunicorn、celery、uvicorn）必须显式指定解释器全路径，例如：/opt/python-3.11.9/bin/python -m gunicorn app:app
WSGI/ASGI 服务器启动时卡住或报 ImportError: No module named 'encodings'
这是最常踩的坑：新 Python 安装后没带标准库路径，或者 LD_LIBRARY_PATH 指向了旧版本的 libpython。错误不是缺包，是解释器连自己都初始化不了。
验证方式很简单：在目标环境下直接运行 /opt/python-3.11.9/bin/python -c "print('ok')"。如果报这个错，说明安装不完整或环境变量污染。
立即学习“Python免费学习笔记（深入）”；
- 编译安装 Python 时务必加
--enable-shared，否则动态链接库缺失 - 确认
/opt/python-3.11.9/lib/libpython3.11.so存在，且LD_LIBRARY_PATH包含该路径（注意：仅对当前启动命令生效，别全局 export） - 用
ldd /opt/python-3.11.9/bin/python检查是否链接到正确的libpython，避免混用系统自带的libpython3.9
升级后 Celery worker 启动失败，日志里反复出现 ModuleNotFoundError: No module named 'pkg_resources'
这不是 setuptools 没装，而是新 Python 环境里没初始化 pip 生态。Python 3.11+ 默认不自带 pkg_resources，它现在是 setuptools 的一部分，但必须显式安装才能激活。
尤其在容器或最小化系统中，python -m ensurepip 可能被禁用，导致 pip 命令存在但无法安装任何东西。
- 先运行
/opt/python-3.11.9/bin/python -m ensurepip --upgrade --default-pip - 再执行
/opt/python-3.11.9/bin/python -m pip install --upgrade setuptools wheel - Celery 5.3+ 要求
setuptools>=61.0，低于这个版本会静默失败，别跳过升级
用 systemd 管理多 Python 版本服务时，reload 不触发进程替换
systemctl reload myapp.service 默认只发 SIGHUP，而 gunicorn 或 uvicorn 是否响应、如何响应，完全取决于你启动时有没有加 --preload 或 --reload —— 这俩在生产环境都是反模式。
真正可控的方式是：把 reload 拆成两步——先启动新进程，等就绪后再优雅停掉旧进程。systemd 本身不支持“蓝绿切换”，得靠外部协调。
- 在 service 文件里用
Type=notify，配合gunicorn --preload --graceful-timeout 30，确保主进程收到systemctl restart后能等 worker 完成请求再退出 - 避免用
Restart=always：新 Python 下某个依赖初始化失败，会导致无限重启循环，掩盖真实问题 - 上线前必须测试
systemctl start myapp@v311.service（独立 unit），确认日志里有Booting worker with pid且无 traceback
真正的难点不在升级动作本身，而在验证——每个服务的“就绪”定义不同：gunicorn 看端口监听，celery 看 celery -A app inspect ping，而数据库连接池是否 warm-up 完全得靠业务日志判断。漏掉这一环，零停机就是假象。
