使用virtualenv创建Python3虚拟环境时引入多余库及报错问题
作为踩过无数虚拟环境坑的老玩家，我来给你捋几个最常见的原因，以及对应的解决办法：
1. 系统Python的包被偷偷继承了
很多人不知道，virtualenv默认是不继承系统site-packages里的包，但如果你的环境里有VIRTUALENV_SYSTEM_SITE_PACKAGES这个环境变量被设为true，或者你创建环境时不小心加了--system-site-packages参数，甚至是~/.virtualenv配置文件里默认开了这个选项，都会导致系统里装的所有包被带进虚拟环境。
怎么验证？ 激活环境后跑这条命令：
python -c "import sys; print('\n'.join(sys.path))"
如果输出里出现了系统级的site-packages路径（比如/usr/lib/python3.8/site-packages），那就是这个问题没跑了。
解决办法：
- 删除旧环境，重新创建时明确加上
--no-site-packages（虽然新版本virtualenv默认就是这个，但保险起见加上）：rm -rf venv && virtualenv -p python3 --no-site-packages venv - 检查你的shell配置文件（
.bashrc/.zshrc），看看有没有设置VIRTUALENV_SYSTEM_SITE_PACKAGES，有的话删掉那行。
2. 旧虚拟环境残留的垃圾
如果你之前创建过同名的venv目录，没彻底删除就重新创建，virtualenv有时候不会完全覆盖旧文件，导致之前装的包残留下来。这种情况很容易被忽略，但确实常见。
解决办法：
- 先彻底删掉旧环境：
rm -rf venv - 再重新创建干净的环境。
3. PYTHONPATH环境变量在搞鬼
PYTHONPATH是Python用来查找模块的优先级路径，如果你全局设置了这个变量，哪怕激活了虚拟环境，Python还是会优先加载PYTHONPATH里的包，看起来就像是虚拟环境自带的一样。
怎么验证？ 激活环境后跑：
echo $PYTHONPATH
如果输出不是空的，那就是它的问题。
解决办法：
- 激活环境后临时取消这个变量：
unset PYTHONPATH - 永久解决的话，去你的shell配置文件里删掉设置
PYTHONPATH的那行。
4. virtualenv本身的版本/安装问题
你提到用virtualenv -p python3 venv报错，很大可能是virtualenv本身和你的Python版本不兼容，或者是用系统pip装的virtualenv太老了。
替代方案：
其实Python3.3+自带了venv模块，比第三方的virtualenv更稳定，而且是官方维护的，建议直接用这个：
rm -rf venv && python3 -m venv venv
激活环境的方式和virtualenv一样：source venv/bin/activate
最后再做一次干净的测试
按这个流程走，绝对能得到纯净的虚拟环境：
- 关闭当前终端，打开一个全新的终端（避免之前的环境变量干扰）
- 删掉旧环境：
rm -rf venv - 创建新环境：
python3 -m venv venv - 激活：
source venv/bin/activate - 检查版本：
python --version（应该和你指定的python3一致） - 检查包：
pip freeze（正常情况下只会有pip、setuptools、wheel这几个基础工具，这是默认自带的，不属于多余包）
内容的提问来源于stack exchange，提问作者merry-go-round
