Python venv激活后加载全局包致requests导入报错排查

这是典型的虚拟环境隔离未生效问题：虽然shell的PATH优先级已经把venv的bin目录放到最前（所以which python3.10返回venv内路径），但Python解释器启动时没有识别到自己运行在虚拟环境中，导致sys.prefix回退到全局路径/usr，sys.path优先加载全局site-packages下的依赖，才会读到系统里安装的旧版本urllib3，触发Mapping导入错误。
你venv里安装的urllib3 1.26.9本身已经修复了Python 3.10的兼容性问题，只要隔离逻辑正常，这个报错会直接消失。

• 检查venv根目录下的pyvenv.cfg配置
  这是venv识别环境的核心配置文件，正常内容应该类似如下结构：

  home = /usr/bin
  include-system-site-packages = false
  version = 3.10.4
  executable = /usr/bin/python3.10
  command = /usr/bin/python3.10 -m venv /home/mikhail/Projects/Github/python/socialize/venv/
  

  重点确认两个点：home字段指向全局Python 3.10的所在目录（也就是/usr/bin），include-system-site-packages为false。如果文件缺失、内容损坏、字段路径错误，解释器就无法正确设置虚拟环境前缀。
• 排查PYTHONPATH环境变量干扰
  激活venv后执行echo $PYTHONPATH，如果有输出值，说明全局shell配置里提前把全局包路径写入了Python搜索路径，会覆盖venv的包优先级。临时修复直接执行unset PYTHONPATH即可，长期修复需要把.bashrc/.zshrc里写死的PYTHONPATH配置行删除。
• 检查venv内Python二进制的软链接状态
  执行如下命令查看软链接指向：

  ls -l venv/bin/python*
  

  正常情况下venv/bin/python3.10应该软链接到全局的/usr/bin/python3.10，如果软链接损坏、指向错误，直接重建即可：

  ln -sf /usr/bin/python3.10 venv/bin/python3.10
  ln -sf python3.10 venv/bin/python
  

• 全量重建虚拟环境（最快兜底方案）
  如果以上检查没定位到明确问题，直接删除旧环境重建即可：

  deactivate
  rm -rf venv/
  /usr/bin/python3.10 -m venv venv/
  source venv/bin/activate
  

  重建后先执行python -c "import sys; print(sys.prefix)"验证，输出为venv目录路径就说明隔离正常，再安装依赖即可。

内容的提问来源于stack exchange，提问作者Mikhail