Ubuntu下Python虚拟环境virtualenv详解：从安装到依赖管理实践

1. 为什么Python项目离不开virtualenv——先弄明白这关为什么必须过

做过几年Python开发的人，基本都经历过这么一件事：某个项目依赖requests 2.25，另一个项目要用requests 3.0的新接口，两个项目都不能改代码，但你本机只有一套全局环境，装哪个都会让另一个项目挂掉。更头疼的是，系统自带的Python还承担着某些系统工具的运行职责，你一pip install，可能直接把系统的包管理环境搅乱了。这就是我要聊virtualenv的原因：它是解决多个Python项目依赖冲突、实现版本控制的最基础、最可靠的办法。

很多刚接触Python的同学会觉得，虚拟环境是个"多此一举"的东西，直接用全局环境不好吗？如果你只是写点一次性脚本，确实无所谓；但但凡你要做一个超过一个月的项目、要和其他人协作、或者要部署到服务器，全局环境那套玩法就会让你痛不欲生。

1.1 全局环境依赖的三大痛点

先说第一个痛点：不同项目的依赖版本互相踩踏。比如A项目需要Django 2.2，这是它长期稳定的版本，你不敢动；B项目非要Django 4.2不可，因为业务代码用到了新版特性。在同一个全局环境里，这两者几乎不可能共存，就算你能找到某种"降级再升级"的骚操作，下一次pip install某个新包时又会把所有东西重新搅乱，彻底失控。

第二个痛点是权限问题。Ubuntu系统自带的Python位于/usr/lib/python3，这个目录是root所有。普通用户直接执行pip install xxx要么被拒绝，要么弹出externally-managed-environment的报错（Ubuntu 23.04之后特别明显）。于是要么硬着头皮用sudo装，要么用--break-system-packages强行打破管控。前者会污染系统环境，后者等于自己放弃了保护机制，总有一天会付出代价。

第三个痛点是复现困难。你在自己机器上能跑的项目，换一台干净的机器，装完依赖直接跑不起来，这几乎是新人必踩的坑。原因就是全局环境里"没有记录的包太多了"，你以为只需要pip install flask，实际跑起来才发现还缺flask-cors、flask-sqlalchemy、python-dotenv，这些全是之前某次操作顺手装的。没有虚拟环境，你就没法生成一份干净、可复现的依赖清单。

virtualenv就是为这几个问题而生的：它在你项目目录下创建一个独立的Python环境，里面有独立的bin、lib、site-packages，你在这个环境里怎么折腾都不影响系统Python，也不会影响其他项目。

1.2 virtualenv的核心原理：其实只动了三样东西

理解virtualenv的原理之后，很多使用中的困惑都会迎刃而解。

创建一个虚拟环境后，你去看它的目录结构，会发现三个关键部分：

• bin/：存放Python解释器的软链接、pip、activate激活脚本
• lib/pythonX.X/site-packages/：独立第三方包安装目录
• pyvenv.cfg（或者其他配置文件）：记录这个虚拟环境对应的基础Python版本路径

当你source venv/bin/activate的那一刻，shell的PATH变量被改写了，排在最前面的是venv/bin。也就是说，你输python时，系统找到的是venv/bin/python；输pip时，找到的是venv/bin/pip。这两个工具自然会去venv/lib/pythonX.X/site-packages找包，而不是去系统的/usr/lib/python3。

用一句话概括：virtualenv做的就是"改路径"这件事，逻辑上和你在PATH里加一个属于自己项目的工具目录没有本质区别。只不过它把这个工具目录做成了可直接执行的完整Python环境，里面自带了解释器链接、包管理和激活脚本。

1.3 和venv、pipenv、conda的区别：选哪个得看场景

很多教程会把virtualenv和venv混着说，其实要区分一下：

• venv：Python 3.3以上自带的标准库模块，功能是virtualenv的"官方精简版"。它能满足绝大多数基础的虚拟环境需求，但创建速度稍慢、扩展功能有限，尤其缺少复制Python可执行文件的能力，本质上是软链接或复制一套目录结构。
• virtualenv：第三方独立工具，Python 2时代就开始用，兼容性更好，创建速度快，支持指定任意Python版本，甚至支持Python 2和Python 3共存于不同虚拟环境。它有可执行文件复制（--copies）和符号链接（--symlinks）两种模式，处理跨Python版本场景时更灵活。
• pipenv：在virtualenv上层加了Pipfile、锁文件和依赖工作流管理，适合对依赖管理有更高要求的项目。
• conda：不只是Python虚拟环境，而是完整的包管理器和环境管理器，适合科学计算、数据处理场景，因为很多底层库（比如numpy、scipy）用conda安装能避免编译地狱。

我的建议是：如果你用Ubuntu做常规Web开发、脚本开发，就老老实实学virtualenv，它是理解虚拟环境概念的最佳入门工具，也是你后面理解所有高级工具的底层基础。这个文章后续的所有操作都以Ubuntu + virtualenv为主线展开。

2. Ubuntu下安装virtualenv：三种方法怎么选

确定用virtualenv之后，下一步就是在Ubuntu上把它装好。这里有三条路可以走，每条路都有自己的适用场景和坑，我逐个说说，然后给出我的推荐。

2.1 方法一：用apt直接安装，适合急着上手的人

Ubuntu的软件源里直接有virtualenv，一条命令就能装：

sudo apt update sudo apt install python3-virtualenv

装完之后直接执行virtualenv --version就能看到版本号，非常省事。

但这条路有两个问题。第一是版本滞后。Ubuntu软件源里的virtualenv版本往往比PyPI上的落后不少，尤其是Ubuntu LTS这种长期支持版本，源里的包版本可能停在两年前。虚拟环境工具本身更新不频繁倒也问题不大，但如果遇到bug修复，你就得等到下一个Ubuntu版本或者自己换源。第二是它默认根据/usr/bin/python3创建环境，如果你想用某个特定版本的Python（例如项目非要Python 3.8），还得额外装对应的python3.8并手动指定，操作起来比直接用pip装要绕。

如果你是第一次接触virtualenv、想先跑通流程，apt安装完全够用；但如果你打算长期依赖这个工具，我不建议把apt作为主力安装来源。

2.2 方法二：用pip装进用户目录，我最常用的做法

我的推荐方式是：用pip把virtualenv装到用户目录，而不是系统目录，这样既绕开了权限问题，又能保证版本较新。

# 先确保pip本身可用，然后用用户级安装 python3 -m pip install --user virtualenv

装完之后可能需要做一件事：把用户安装的命令路径加入PATH。Ubuntu上通常这个路径是~/.local/bin，执行以下命令检查：

export PATH="$HOME/.local/bin:$PATH" # 想永久生效就写入bashrc echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc source ~/.bashrc

然后验证：

virtualenv --version

这样装的virtualenv只服务于你自己，不会影响系统Python，也不会有externally-managed-environment报错。之后想升级也特别简单：

python3 -m pip install --user --upgrade virtualenv

2.3 方法三：用pipx安装，最干净的隔离方案

当你的职责范围不只是自己开个虚拟环境，而是需要维护多台机器、要给不同用户共享环境的时候，我会多推荐一种方式：pipx。

pipx做的事情很纯粹：把命令行工具装进它自己隔离的环境中，然后生成一个软链接到~/.local/bin。用它装virtualenv，virtualenv本身不会待在某个项目的venv里，也不会污染用户环境。

sudo apt install pipx pipx install virtualenv

后续升级：

pipx upgrade virtualenv

这条路的优点是干净，但多引入了一个工具链。对大多数人来说，方式二已经足够，pipx更像是在你已经熟悉了virtualenv之后的一种进阶选择。

2.4 三种方式对比与推荐结论

我用一张表整理一下三种方式的核心差异：

我个人到目前为止经历了三个阶段：最早用apt懵懂地跑通流程，后来一直用pip install --user作为主力，最近因为要给多人共用的一台工作站搭环境，转到了pipx，体验很不错。如果你刚起步，照着方式二做就行，想清楚"为什么要这样装"就已经比大多数人强了。

3. 创建、激活与销毁虚拟环境：标准操作与习惯设计

装了virtualenv，接下来说说日常最常使用的一套流程。这部分内容看起来简单，但实际上有很多藏得很深的细节和习惯设计问题，值得认真琢磨。

3.1 创建虚拟环境：命令的含义和常用参数

进入你的项目目录，执行：

cd /path/to/your/project virtualenv venv

这个命令的意思是：在当前目录下创建一个名为venv的文件夹，里面装一个独立的Python环境。venv这个名字不是强制规定的，但如果你用其他名字，比如.env，就要特别注意别和系统里某些工具默认读取的文件冲突。我建议就用venv，这是社区事实上的标准，很多.gitignore模板和工具都默认忽略它。

创建时最常用的两个参数：

# 指定Python版本，适合系统里装了多个Python的情况 virtualenv -p python3.8 venv # 用系统Python的可执行文件做复制而非软链接，兼容性更好 virtualenv --copies venv

-p参数在项目有固定Python版本要求时几乎是必用的。比如你是为某个旧项目维护环境，项目要求Python 3.6，但系统默认是Python 3.10，你不指定版本就创建，后面激活后python --version是3.10，代码可能直接语法错误，这个坑很多人踩过。

3.2 激活、确认、退出与删除：完整的生命周期

创建之后，激活命令是：

source venv/bin/activate

激活后你会看到shell提示符前面多了一个(venv)前缀。这说明你当前已经在虚拟环境里了。为了确保一切正常，可以执行：

python --version which python pip --version

此时which python应该指向项目目录下的venv/bin/python，which pip应该指向venv/bin/pip。看到这两个输出符合预期，就说明环境激活成功，接下来的所有pip install都会装进这个虚拟环境里。

退出环境特别简单：

deactivate

deactivate是一个shell函数，由激活脚本定义，退出后就回到系统环境。这个命令在任何目录下都能执行，因为它记录的是环境变量的改动。

删除环境更简单——直接把整个目录删掉就行：

rm -rf venv

因为虚拟环境本质就是一个自包含目录，不存在"卸载"的概念。要重建就直接重新创建，通常配合着requirements.txt一起用，几分钟就能把环境恢复得像没删过一样。

3.3 为什么不建议在.bashrc里自动激活

有些同学图省事，把source venv/bin/activate写进~/.bashrc，这样每次打开终端都自动进入某个虚拟环境。我试过这种做法，后来果断弃了。

原因有两点：其一，你不可能每个项目都在同一目录下开发，~/.bashrc里写死了某个路径，换项目就等于环境失效，这种"自动"反而成了负担；其二，自动激活会让人忽略"我现在在哪个环境"这个基本意识，等哪天真忘了手动激活，直接把包装进了系统Python，那种"全局污染"的后果比任何缺陷都难收拾。

正确习惯是：进入项目目录，手动激活环境，结束后主动退出。养成这个肌肉记忆，你以后就不会问"为什么我代码跑到一半说模块找不到"这种问题了。

3.4 虚拟环境目录规划：项目绑定的最佳实践

关于venv放哪里，常见的做法是放在项目根目录下面。但这在Git协作中有个潜在问题：别人克隆你的仓库时不会下载venv（因为.gitignore忽略了它），他需要自己重建环境。所以我的习惯是：

• venv放在项目根目录，用.gitignore忽略掉
• 项目根目录只放代码和requirements.txt
• 新建环境时用virtualenv venv，创建后第一时间激活并安装依赖

这样的好处是：环境与项目一一对应，你永远不会弄混当前项目需要哪个Python版本，也不会跨项目误用环境。相比"全局环境里装了一堆包"，这种"每个项目一个洁癖环境"的做法在长期维护时简直是一种享受。

4. 让版本控制真正闭环：virtualenv + requirements.txt + Git

装好virtualenv只是第一步，真正让"版本控制"这四个字生效的，是把virtualenv和依赖清单、代码仓库结合起来。这套组合拳打好了，你换机器、换同事、上服务器，都只需要一条命令就能复现环境。

4.1 用pip freeze生成锁定的依赖清单

在虚拟环境激活状态下，执行：

pip freeze > requirements.txt

这条命令会把当前环境已安装的所有第三方包，连同精确的版本号输出到requirements.txt中。比如：

Flask==2.2.3 Jinja2==3.1.2 Werkzeug==2.2.3 gunicorn==20.1.0 python-dotenv==0.21.0

这里的==是精确保留版本的意思，确保在任何机器上安装出来的依赖和你开发环境完全一致。

但要注意一点：pip freeze会把虚拟环境里所有包都列出来，包括某些包间接依赖的东西。这会让requirements.txt变得很长并且有一些"你不一定认识"的包，这是正常现象，不要随手删掉那些不认识的行，因为那些可能是某个主依赖库的内部依赖，删了之后环境不一定能正常工作。

4.2 手动维护还是自动生成：我的做法

网上关于"requirements.txt怎么维护"的说法五花八门，我实战之后总结出的经验是分两种情况：

• 对于项目启动早期，依赖还在频繁变动，我建议手动维护一份精简的requirements.txt，只写顶级依赖，比如Flask、requests、SQLAlchemy这些你自己直接用的库。这样别人一看就知道项目用了什么技术栈，而非被几十行间接依赖搞得头大。
• 项目进入稳定期后，切换成pip freeze导出的完整锁定版，保证任何人任何机器装出来的环境逐字节一致。

还有一个做法我强烈推荐：区分requirements.txt和requirements-dev.txt。生产环境只装运行依赖，开发环境额外装测试、lint、调试相关的包。在requirements-dev.txt里写两行就能实现：

-r requirements.txt pytest==7.1.2 flake8==5.0.4

-r表示把前者也包含进来，这样部署时直接用requirements.txt，开发时用requirements-dev.txt，分工明确。

4.3 配合Git使用的关键配置

既然是版本控制，Git这边有几件事必须做好。

第一，创建.gitignore并确保包含venv/。这行看起来不起眼，但没它就会出现一个项目里所有代码加起来几百KB、venv目录却动辄几百MB的情况，更重要的是，venv里装的是本机路径相关的文件，推到Git仓库里别人也用不了，只会制造噪音和垃圾。

第二，依赖清单必须进版本库。requirements.txt应该和代码一起提交，这样别人拿到代码的同时就能拿到环境定义，只需要执行下面的安装命令：

pip install -r requirements.txt

第三，删掉venv重来是最好的"重新锁定"方式。当项目运行周期拉长，旧虚拟环境里堆积了大量无效包以后，我会把venv整个删掉，用requirements.txt重新创建环境。此时你会发现最简单可靠的流程其实是：

rm -rf venv virtualenv -p python3.10 venv source venv/bin/activate pip install -r requirements.txt

这个过程走一遍，你不仅清理了环境里的垃圾依赖，还能验证requirements.txt是不是真的完整可用。我基本每隔一两个月就对长期项目做一次这种"重建验证"，效果特别好，能及早发现依赖缺失这样的隐患。

4.4 在新机器上从零复现环境的完整流程

最后，把整套流程串起来。拿到一台全新的Ubuntu，从零开始运行一个Python项目，我的操作顺序是：

# 1. 安装基础工具 sudo apt update sudo apt install -y python3-pip git python3 -m pip install --user virtualenv # 2. 克隆代码 git clone <repo-url> cd <repo-name> # 3. 创建并激活环境 virtualenv -p python3.10 venv source venv/bin/activate # 4. 安装依赖 pip install -r requirements.txt # 5. 验证环境 python -c "import flask; print(flask.__version__)"

执行完这五步，你的环境和开发机就保持一致，可以正常跑了。多台机器之间想同步环境，也只需要更新代码和requirements.txt，然后重新执行第3、4步就够了。

5. 我在Ubuntu+virtualenv上踩过的坑（实测经验）

做技术分享如果不聊坑，总觉得少了点灵魂。下面几个问题，是我自己在Ubuntu环境下用virtualenv时真实遇到并且花时间排查过的，记录一下，希望你能绕开。

5.1 Ubuntu 23.04以上版本的externally-managed-environment报错

从某个版本的Ubuntu开始，系统Python对pip的管控越来越严格，直接运行pip install通常会报错：

error: externally-managed-environment This environment is externally managed

这个报错的意图是防止用户通过pip往系统Python里乱装包，导致系统和APT管理的包冲突。遇到它不要慌，更不要直接加--break-system-packages硬装。正确做法是立刻转而使用虚拟环境——这恰好也是我们这个工具存在的意义。

如果你用的是虚拟环境，这段报错再也不会出现，因为虚拟环境里不存在"externally-managed"的概念。所以如果你在官方源升级Ubuntu版本后发现pip突然"坏了"，先确认自己是不是在最开始就用错了方式，该virtualenv登场时就不要恋战。

5.2 命令virtualenv和python3 -m virtualenv的差异

有段时间我特别困惑：为什么有时候virtualenv venv好用，有时候提示virtualenv: command not found，但python3 -m virtualenv venv却一直好用。

其实原因很简单：在方式二(user pkg)安装时，~/.local/bin如果没有加进PATH，命令行里的virtualenv就找不到，但用python3 -m virtualenv，只要python3能找到这个模块，执行就不受PATH限制。所以当命令行方式报"command not found"时，先检查PATH配置，而不是急着重装两次。

我看过不止一个开发者因为这个问题反复重装virtualenv，结果都是无效操作。真正要解决的问题是把~/.local/bin纳入PATH。

5.3 激活虚拟环境后pip仍然指向系统目录

这种情况一般出现在环境创建时用了--system-site-packages，或者你在激活状态下执行过带路径前缀的pip命令。比如：

/usr/bin/pip install xxx

一旦用了这种方式，安装的包会跑到系统Python的site-packages里，而这个虚拟环境根本看不到。更麻烦的是，因为你已经激活了环境，pip命令本身会被环境接管，但你手动加绝对路径就等于绕道了，这种误操作特别隐蔽。

我的建议是：在激活状态下，永远只用裸命令pip或者python -m pip，不要手滑打出具体路径。如果执行了上述误操作，排查的方法也简单：

pip --version

看输出里的路径是venv/bin/pip还是/usr/bin/pip，一旦是后者，就该用deactivate退出再重新激活，或者干脆删掉venv重建。

5.4 虚拟环境目录移动后失效的问题

virtualenv创建时，环境内的激活脚本会在脚本里写入一条固定路径。比如你创建在/home/user/project/venv，激活脚本里的VIRTUAL_ENV字符串就是这段绝对路径。如果你之后把项目文件整体移动到别的位置，原样直接source venv/bin/activate常常会报错，或者激活后which python指向的是一个不存在的旧路径。

遇到这种情况，最省心的做法是删掉venv重新创建，不要试图手动去改脚本里的路径。因为除了激活脚本，还有pyvenv.cfg文件里的路径关联，手动改很容易漏。反正有了requirements.txt，一分钟恢复环境，没必要折腾。

5.5 不同Python版本下Numpy等包安装失败的提示

如果你的项目依赖Numpy这类带编译代码的包，而且用-p参数指定了一个比较老的Python版本，经常会出现"没有预编译wheel""编译期间报错"这类问题。这不是virtualenv的锅，而是所选Python版本和包版本不匹配的问题。

我的经验是：在Ubuntu上做科学计算类项目，优先用Python 3.8以上版本创建环境，并且不要用项目里规定之外的老版本去强行兼容老环境，否则等待你的可能就是一连串gcc编译报错。如果是维护老项目不得已使用老版本，可以优先检查对应的包有没有提供该平台、该Python版本的预编译包，如果没有，再考虑是否值得花时间去编译。

6. 结合virtualenv再做一层环境防护：给系统的Python"上锁"

很多读者可能意识不到，虚拟环境不仅解决"项目之间冲突"的问题，它同时也是系统完整性的一道防线。既然我们已经这么依赖virtualenv来管理项目依赖，那就该考虑把系统Python"锁起来"，从源头杜绝手滑把包装进系统环境。

Ubuntu上可以用一个做法：给系统pip设置一个默认配置文件，让它在没有显式虚拟环境时拒绝运行。具体做法是创建~/.config/pip/pip.conf：

[global] require-virtualenv = true

加了这一行之后，任何不在虚拟环境中的pip操作都会直接报错退出，从而杜绝"全局安装"。如果你确实想装一个全局工具（比如virtualenv本身），就在命令行加--user或者用pipx安装，这两者都不受影响。

这样设置之后，你自然就会养成"先用virtualenv再pip install"的习惯，系统Python也能一直保持干净。很多人总是抱怨系统环境莫名其妙坏掉，其实大部分情况就是"以为自己在虚拟环境里，其实没有，顺手装了个包把系统搞坏了"。这个配置能从根本上绕开这类问题。

另外，如果你管理着一批服务器，还可以配合pip freeze定期把所有虚拟环境的依赖清单备份到一处，等哪天环境彻底坏了，直接用备份重建。环境这种"仪式感"在多人协作或生产环境里，往往比代码本身还重要。

我自己在实际工作里的习惯是：每台Ubuntu机器装好Python之后，第一件事就是装virtualenv，第二件事就是设置require-virtualenv，第三件事是给每个项目创建独立环境。三者配合下来，之后再没遇到过"环境又坏了"这样的问题。

最后再分享一个半自动化小技巧：在项目根目录放一个Makefile，把环境创建、激活、安装、清理这几件事写成固定命令，例如：

setup: python3 -m virtualenv venv @echo "run: source venv/bin/activate" install: pip install -r requirements.txt clean: rm -rf venv

这样无论是你自己还是新加入的同事，只需要执行make setup就能把环境建起来。省去记忆命令的痛苦，也避免每个人因为输入命令不一致而导致环境差异。长期实践下来，这种小碎步的自动化虽然不起眼，却是提升项目易上手度和稳定性的关键一步。