Ubuntu下source激活venv成功但仍调用系统Python/pip故障求助
执行虚拟环境激活命令后终端显示(venv)激活标识，但实际调用的python、pip均指向系统全局路径下的/usr/bin/python、/usr/bin/pip，未使用虚拟环境内的对应程序。
复现操作：
/my_project$ source venv/bin/activate (venv) /my_project$
验证路径时输出全局程序位置：
(venv) /my_project$ which python /usr/bin/python (venv) /my_project$ which pip /usr/bin/pip
- 操作系统：Ubuntu 20.04.4 LTS
- 系统默认Python版本：3.8.10
- 自行安装Python版本：3.10.5
- 虚拟环境创建命令：
python3.10 -m venv venv - 补充说明：同命令在全新目录创建的虚拟环境可正常使用，故障虚拟环境为系统重启前创建，重启后出现异常。
这个问题本质是旧虚拟环境的硬编码路径失效：Python自带的venv在创建时，会把用到的解释器绝对路径、虚拟环境自身的存放绝对路径直接写死在激活脚本、pip/python的启动配置里。只要创建后移动过项目目录、或者自行安装的Python3.10存放路径发生变化（重启后磁盘挂载点变化、手动挪动过解释器文件都算），就会出现“能显示(venv)前缀但调用全局程序”的情况——激活脚本只负责修改终端前缀和PATH优先级，一旦写死的解释器路径找不到，系统就会顺着PATH找全局的Python/Pip顶替。
少数情况是shell配置文件里写了Python/Pip的全局别名，强制覆盖了虚拟环境的程序优先级。
- 先彻底退出异常虚拟环境，执行：
deactivate
如果执行完终端前缀的(venv)标识未消失，直接关闭当前终端重开，确保未处于任何虚拟环境中。
2. 验证当前Python3.10的实际存放路径，执行：
which python3.10
记下输出的绝对路径，正常应为类似/usr/local/bin/python3.10的非系统默认路径。
3. 可选操作：备份旧环境已安装的依赖列表，避免后续重复安装：
./venv/bin/pip freeze > requirements.txt
如果这步报错提示路径不存在、找不到命令，直接跳过即可，后续手动安装所需依赖就行。
4. 删除失效的旧虚拟环境：
rm -rf venv
- 用步骤2查到的Python3.10绝对路径重新创建虚拟环境，不要直接用
python3.10命令，避免别名或软链接异常导致硬编码出错，比如查到的路径是/usr/local/bin/python3.10就执行：
/usr/local/bin/python3.10 -m venv venv
- 重新激活虚拟环境并验证：
source venv/bin/activate which python which pip
此时输出路径应为/my_project/venv/bin/python、/my_project/venv/bin/pip，即代表虚拟环境恢复正常。
7. 如果之前导出了依赖列表，直接执行命令重装依赖即可：
pip install -r requirements.txt
如果重建虚拟环境后仍然调用全局程序，激活后执行以下命令检查是否存在全局别名覆盖：
alias | grep python alias | grep pip
如果输出存在将python/pip绑定到全局路径的别名规则，编辑对应的shell配置文件（bash对应~/.bashrc，zsh对应~/.zshrc），删除对应的别名配置行，执行source ~/.bashrc（或对应shell的配置文件）后重新激活虚拟环境即可。
- venv本身不支持直接目录迁移，虚拟环境创建完成后不要随意移动项目文件夹位置，必须移动的话删除旧环境在新路径下重建即可。
- 不要用临时挂载目录、移动存储介质里的Python解释器创建虚拟环境，重启后挂载点失效就会出现同类问题。
内容的提问来源于stack exchange，提问作者Jawad Mehmood
