3、虚拟环境：virtualenv的安装与使用、venv模块的使用、虚拟环境的激活与退出
说到网络配置下的包依赖问题，我第一个想聊的就是虚拟环境。
你想想看，我们做网络自动化，Python脚本里动不动就要装 netmiko、napalm、paramiko、ncclient 这些库。今天这个项目要 netmiko 3.x，明天那个项目可能只兼容 2.x。要是全装到系统 Python 里，那不乱套才怪。
虚拟环境就是干这个的——给每个项目一个独立的 Python 小天地。说白了，就是隔离。
3.1 virtualenv：老牌工具，依然能打
virtualenv 是 Python 虚拟环境的元老级工具。我最早接触它是在 2015 年，那时候还没有 venv 模块，大家全靠它。
安装 virtualenv
如果你用的是 Python 2 或者比较老的 Python 3 版本，virtualenv 需要单独安装：
pip install virtualenv我个人习惯用 pip list 确认一下安装是否成功：
pip list | grep virtualenvvenv 模块，不一定非要装 virtualenv。但我还是建议你两个都了解，毕竟有些老项目还在用 virtualenv。
创建虚拟环境
假设我们有个网络自动化项目，叫 net_auto_project。进入项目目录后，执行：
virtualenv venv这条命令会在当前目录下生成一个 venv 文件夹。里面包含了独立的 Python 解释器、pip、以及标准库。
如果你想指定 Python 版本，比如用 Python 3.8：
virtualenv -p /usr/bin/python3.8 venv我在项目中遇到过一个问题：服务器上有多个 Python 版本，默认的 python3 是 3.6，但某个库只支持 3.8+。这时候 -p 参数就派上用场了。
激活与退出
创建好虚拟环境后，得激活它才能用。不同操作系统命令不一样：
| 操作系统 | 激活命令 |
|---|---|
| Linux / macOS | source venv/bin/activate |
| Windows (CMD) | venv\Scripts\activate.bat |
| Windows (PowerShell) | venv\Scripts\Activate.ps1 |
激活后，你会看到命令行前面多了 (venv) 字样。嗯，看到这个就说明你已经在虚拟环境里了。
退出很简单，直接敲：
deactivate(venv)。
3.2 venv：Python 3 自带的亲儿子
从 Python 3.3 开始，官方就内置了 venv 模块。它的用法和 virtualenv 几乎一样，但不需要额外安装。
创建虚拟环境
同样在项目目录下：
python3 -m venv venv注意这里的 -m venv 是调用模块的方式。第一个 venv 是模块名，第二个 venv 是目录名。你也可以改成别的名字，比如 python3 -m venv myenv。
我个人更推荐用 venv，原因有三：
- 不用额外安装，开箱即用
- 官方维护，兼容性好
- 轻量，没有多余依赖
激活与退出
激活命令和 virtualenv 完全一样：
# Linux / macOS
source venv/bin/activate
# Windows
venv\Scripts\activate退出也是 deactivate。
virtualenv 支持 Python 2 和更老的 Python 3 版本，而 venv 只支持 Python 3.3+。如果你还在维护 Python 2 的老项目，那只能用 virtualenv。
3.3 虚拟环境的激活与退出：细节决定成败
激活和退出看起来简单，但有几个细节我不得不提。
激活后发生了什么？
激活虚拟环境后，PATH 环境变量会被修改。系统会优先使用 venv/bin 目录下的 Python 和 pip。所以当你执行 python 或 pip 时，实际上用的是虚拟环境里的版本。
你可以用 which python 或 where python 来验证：
# 激活前
$ which python
/usr/bin/python3
# 激活后
$ source venv/bin/activate
(venv) $ which python
/home/user/net_auto_project/venv/bin/python3看到路径变了，说明环境生效了。
退出后呢？
执行 deactivate 后，PATH 会恢复原样。Python 和 pip 又指向系统默认的了。
pip install 装了一堆包，然后直接关掉了终端。下次打开新终端，忘了激活环境，又用 pip install 装了一遍。结果系统 Python 里也装了一份，虚拟环境里也装了一份。后来排查问题才发现是两套环境混了。所以我的习惯是：每次打开终端，第一件事就是激活对应的虚拟环境。
3.4 知识体系：一张图看懂虚拟环境
下面这张 SVG 图，是我梳理的虚拟环境核心逻辑。你看一眼就能明白整个流程：
这张图从左到右展示了两个工具的选择，然后汇聚到创建环境、激活环境、最后操作。你跟着箭头走一遍，心里就有数了。
3.5 实战建议：我推荐你用哪个？
说了这么多，到底用 virtualenv 还是 venv？
我的建议很简单：
- 新项目：直接用
venv。Python 3.3+ 都自带，省事。 - 老项目：如果项目文档里明确写了用
virtualenv，那就跟着走。别自作主张换工具，容易出兼容性问题。 - 跨版本需求：如果你需要在 Python 2 和 Python 3 之间切换，
virtualenv更灵活。
嗯，虚拟环境这块就聊到这儿。记住一句话：每个项目一个虚拟环境，别偷懒。我在运维生涯里见过太多因为环境混乱导致的故障，真的不值得。