venv 移动/复制目录后失效（bad interpreter: No such file or directory / venv/bin/activate: No such file or directory）

你会遇到什么

项目（连同 venv 目录）挪了位置、拷到新机器、或换用户名路径后，执行 venv 里的命令报 bad interpreter: No such file or directory，报错里出现的旧路径你早就不用了。最迷惑的是 venv/bin/python -V 还能正常输出——看起来环境没坏，但 pip/其它入口脚本全挂。

本文路径：快速修复（30 秒一段命令）→ 一步步排查（可跳读）→ 原理与变体（症状/原因/证据）。赶时间直接跳到「快速修复」。

为什么会这样

venv 里的入口脚本（pip、accelerate、uvicorn 等）第一行 shebang 写的是创建时的绝对路径（#!/old/path/venv/bin/python3）。目录一挪、换用户、换机器，旧路径不存在，内核直接报 bad interpreter（exit 126）。

而 venv/bin/python 本身只是指向系统解释器的软链，跟位置无关，所以还能跑——这就是「python 正常、pip 报错」的真相。kohya_ss#856 是典型：报错里两个路径用户名不同，就是项目从一台机器的用户目录拷到另一用户目录。

实测环境：WSL Ubuntu，python 3.14.4，2026-08-29。

venv 的入口脚本（pip、uvicorn、加速工具等）是「固定 shebang」：创建时把解释器绝对路径写死在第一行（#!/old/path/venv/bin/python3），运行时由内核直接按这个路径启动解释器——目录移动、换用户、换机器后旧路径不存在，内核报 bad interpreter（exit 126）。

而 venv/bin/python 只是指向系统解释器的软链，与位置无关，所以「python 还能跑、pip 报错」是这类问题的指纹。

确定性推论：报错里 shebang 路径与当前路径不一致 = venv 已失效；两条正路——重建 venv（python3 -m venv .venv && pip install -r requirements.txt，最干净）或原地修复（python3 -m venv --upgrade .venv 重写 shebang）；

venv 不该进 git（每台机器路径不同），用 requirements/lock 文件重建；

判断路径：head -1 .venv/bin/pip 看 shebang，与 pwd 对比即知。

一步步来

1. 导出依赖 — 必做

venv/bin/python -m pip freeze > requirements.txt

2. 删掉重建 — 必做

rm -rf venv
python3 -m venv venv

3. 重装依赖 — 必做

venv/bin/python -m pip install -r requirements.txt

4. 重跑入口命令确认 — 必做

venv/bin/accelerate --version

不再报 bad interpreter 即成功。

5. 治本 — 必做

• venv 不进 git，拷项目不连带拷 venv；
• 需要「可移动」环境用 Docker 镜像，或 uv/poetry/conda（按名管理环境，路径无关）；
• source venv/bin/activate 报不存在时：先 ls venv/bin/activate 确认目录是否真的建出来了（常见于创建步骤失败/被 .gitignore 无视），不存在就重建。

临时兜底：venv/bin/python -m pip ... 绕过 shebang 仍可用（实测），但已装的依赖还在旧 site-packages 里，路径一变照样要重装，别当长期方案。

怎么确认修好了

venv/bin/pip --version

正常输出版本号即成功。实测：移动前 pip 25.1.1 正常；mv 后报 bad interpreter（exit 126）；删掉重建 → 装 pyyaml 成功。

其它环境的表现

症状

项目（连同 venv 目录）挪了位置、拷到新机器、或换用户名路径后，执行 venv 里的命令报错：

sh: /Users/XXXi/VLADDiffusion/kohya_ss/venv/bin/accelerate: /Users/dflagmei/VLATDiffusion/kohya_ss/venv/bin/python: bad interpreter: No such file or directory

特征：报错里出现的旧路径你早就不用了；source venv/bin/activate 也可能报 No such file or directory； 最迷惑的是 venv/bin/python -V 还能正常输出版本号，看起来环境没坏。

原因

venv 里的入口脚本（pip、accelerate、uvicorn 等）第一行 shebang 写的是创建时的绝对路径 （#!/old/path/venv/bin/python3）。目录一挪、换用户、换机器，旧路径不存在，内核直接报 bad interpreter（退出码 126）。而 venv/bin/python 本身只是指向系统解释器的软链，跟位置无关， 所以还能跑——这就是「python 正常、pip 报错」的真相。activate 同理：脚本内容是相对引用， 但 venv 目录若被删/没建成功，source 就报文件不存在。kohya_ss#856 是典型：报错里两个路径 用户名不同，就是项目从一台机器的用户目录拷到另一用户目录。

解法

1. 正解：删掉 venv 重建（venv 不保证可移植，别想着修 shebang）：

• 有依赖清单先导出：venv/bin/python -m pip freeze > requirements.txt；
• python3 -m venv venv 重建，再 venv/bin/python -m pip install -r requirements.txt；
• 重跑入口命令确认。

1. 临时兜底：venv/bin/python -m pip ... 绕过 shebang 仍可用（实测），但已装的依赖

还在旧 site-packages 里，路径一变照样要重装，别当长期方案。

1. 治本：venv 不进 git、拷项目不连带拷 venv；需要「可移动」环境用 Docker 镜像、

或 uv/poetry/conda（按名管理环境，路径无关）。

1. source venv/bin/activate 报不存在时：先 ls venv/bin/activate 确认目录是否真的建出来了

（常见于创建步骤失败/被 .gitignore 无视），不存在就重建。