最近在用 Python 写一个个人项目。

Linux 环境里，因为历史原因，安装了很多不同版本。有自带的，有 Anaconda，经常会造成混乱。

因为 Python 小版本间，依旧存在不少兼容性问题。

配置并固定开发环境，困扰了我一阵子。

以前了解，但很少真正使用过 虚拟环境（Virtual Environment） 这类工具。这次找到了特定场景。

1. 背景

如果只是在本地写一个小项目，用之即弃，不必考虑太多，能跑就行。

如果考虑到作为一个正式项目，后期可能上线，那么搭建一个工程化程度更高的本地开发环境，尤为必要。

在我看来，一个好的本地开发环境，应该具有三点特征：

• 效率
• 隔离
• 一致

第一点很好理解。同一个项目，不同开发者需要各自配置开发环境，越简单、快速、准确，效果越好，因为节省下来的时间可以投入到真正的开发中。根据我的经验，繁琐的环境安装过程，非常消耗开发热情。

另外好的开发环境，应该完全独立，不会污染全局或其他环境。

一致指的是线下和线上，不同环境间，运行结果总保持一致。不要小瞧这种一致性，有时即便是微小的不一致，也会成为 bug 的渊薮，万一遇到，极难排查。

总结来说，每个开发环境都应该是一个自洽的独立运行单元。

同时做到这三点，要靠抽象，靠虚拟化（Virtualization）。

对于包管理，Python 早已有一套非常成熟的解决方案：利用 requirements.txt 固定依赖项和版本，借助 pip install 安装。

但这不够。因为 Python 中第三方依赖“全局共享”。

于是 Python 引入虚拟环境，借助它可以轻松地构建一个独立、干净、可复用的开发场景。

2. 虚拟环境演进史

virtualenv 是最早用于创建隔离的 Python 环境的工具。

由于这是一个来自社区的方案，因此需要安装相应的包，但这并不妨碍它后来成为事实标准。

它诞生于 2007 年，作者为 Ian Bicking。

不得不说，这种想法新颖，而且极富预见性。有了 virtualenv 后，Python 项目可以：

• 每个项目独自管理依赖
• 可复制的运行环境
• 不污染全局 Python 环境

很快便流行起来。

并与 requirements.txt 和 pip 一道，极大提高了 Python 工程化的能力，Python 开始变得像一门 “工程语言”。

此时 Python 官方开发者也意识到，虚拟环境是语言级的需要。

因此在 Python 3.3 中，通过引入 venv，在不安装第三方依赖的前提下，提供了官方的、语言级的、虚拟化方案。

与 virtualenv 不同，venv 创建的环境中，不再需要复制整个 Python 解释器，并依靠 pyvenv.cfg 定义环境边界，引导解释器找到对应环境。

简单对比 venv 和 virtualenv：

结论：新的 Python 3 项目，优先使用 venv 。

简单，够用。

3. 使用指南

venv 的使用很简单，和把大象装进冰箱一样，只需要三步：

1. 创建虚拟环境，python -m venv .venv
2. 进入虚拟环境，source .venv/bin/activate
3. 安装依赖，pip install -r requirements.txt

目录下会生成 .venv 文件夹，结构如下：

.venv/
├── bin/
│ ├── python
│ ├── pip
│ └── activate
├── lib/
│ └── python3.x/
│ └── site-packages/
├── include/
└── pyvenv.cfg

bin/python 只是一个指向原 Python 的软链接，真正实现包隔离的是 site-packages：每个虚拟环境，都有单独的包管理。

激活虚拟环境，activate 做了三件事：

1. 修改 PATH。

PATH=.venv/bin:$PATH

于是 python 指向 .venv/bin/python，pip 指向 .venv/bin/pip。

2. 设置环境变量。

   VIRTUAL_ENV=.venv，用于识别当前虚拟环境。

3. 改变命令行提示符。

   例如：(.venv) $

4. 总结

有了 requirements.txt，pip 和 venv 后，Python 项目工程化变得异常简单。

标准开发流程变为：

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

任何一位开发者，在任意一台机器上，都可以轻松获得一份完整、干净、独立，且运行结果高度一致的 Python 环境。

极大降低了环境配置的负担和上线风险。

可以这么说，理解了 venv，就理解了对于脚本语言 Python 而言，为什么需要工程化，以及如何优雅地实现。

一名有着良好自我修养的软件工程师，需要从 Know-How 逐渐过渡到 Know-Why。

（完）

参考

1. virtualenv🔗
2. venv — Creation of virtual environments — Python 3.14.2 documentation🔗
3. Docker - 维基百科，自由的百科全书🔗