别直接复制 Python venv：一次环境迁移故障的定位与重建

现象

项目从 /home/dev/app 搬到 /opt/app 时，.venv 也被完整复制。激活环境后 shell 看似正常，但 pip -V 仍显示旧路径，systemd 启动的 gunicorn 则报 No such file or directory。问题不在权限，而在 venv 内部保存的绝对路径。

为什么复制会失效

venv 至少保存三类位置信息：入口脚本的 shebang、bin/python 等解释器软链接，以及 pyvenv.cfg 里的基础解释器路径。source 只把新目录加入 PATH，不会改写这些内容，所以命令行可能勉强可用，脱离 shell 的服务仍会失败。

可以这样确认：

python -c "import sys; print(sys.prefix); print(sys.base_prefix)"
pip -V
head -n 1 .venv/bin/pip
readlink -f .venv/bin/python

若 pip -V 指向旧目录，基本可以确定环境已经搬坏。

在最终路径重建

不要批量修改 shebang，直接在目标目录创建新环境：

python3 --version
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

有锁文件时优先按锁文件安装。离线环境可先用 pip download 准备 wheel，再用 --no-index --find-links 安装。完成后运行 pip check、最小启动测试和关键单元测试；systemd 服务应使用新解释器的绝对路径，并执行 systemctl daemon-reload。

避免再次踩坑

第一，不把 .venv 当作代码跨机器复制。容器镜像应在构建阶段安装依赖，宿主机用初始化脚本创建环境。

第二，固定 Python 主次版本并维护锁文件，保证依赖可复现。

第三，在 CI 或发布前使用干净环境完成一次安装和启动，及时发现隐藏的路径依赖。

venv 用来隔离依赖，不是可移植的二进制包。迁移时带走代码、锁文件和启动配置，在最终位置重新创建环境，通常比修复搬坏的环境更快、更可靠。