3. 虚拟环境
说实话，我刚入行那会儿，根本不知道虚拟环境是什么东西。
那时候写Python项目，所有依赖全装全局。今天装个Django 2.0，明天项目要用Django 3.2，直接升级全局。结果呢？老项目炸了，新项目也跑不起来。嗯，这种痛，经历过的人都懂。
1.1 为什么需要虚拟环境？
说白了，虚拟环境就是给每个项目一个独立的“小房间”。
每个房间里有自己的一套Python解释器、自己的依赖包。A项目用Django 2.0，B项目用Django 3.2，互不干扰。你想想看，这多省心。
核心痛点：没有虚拟环境时，全局依赖冲突会让你怀疑人生。
我在项目中遇到过最典型的情况：
- 项目A需要
requests==2.25.0 - 项目B需要
requests==2.26.0 - 两个项目同时维护，全局只能装一个版本
怎么办？要么你手动来回切换，要么你就等着某个项目报错。虚拟环境就是来解决这个问题的。
1.2 venv vs virtualenv：选哪个？
Python 3.3 之后，官方内置了 venv 模块。我个人的习惯是：
| 工具 | 适用场景 | 备注 |
|---|---|---|
venv |
Python 3.3+ 标准项目 | 官方推荐，轻量够用 |
virtualenv |
需要兼容 Python 2/3 | 功能更丰富，但需要额外安装 |
如果你用的是 Python 3.3 以上，直接用 venv 就够了。我早期维护过一个老项目，还在用 Python 2.7，那时候只能用 virtualenv。现在嘛，基本都用 venv 了。
我的建议：新项目一律用 venv，除非你有特殊需求。
1.3 创建与使用虚拟环境
来，直接上代码。创建虚拟环境其实就一行命令：
# 使用 venv 创建虚拟环境
python -m venv myenv这会在当前目录下生成一个 myenv 文件夹。里面包含了独立的 Python 解释器和 pip。
激活虚拟环境：
# Windows
myenv\Scripts\activate
# macOS / Linux
source myenv/bin/activate激活后，你会看到命令行前面多了 (myenv) 字样。这时候你安装的所有包，都只在这个环境里生效。
注意：我曾经犯过一个低级错误——忘记激活虚拟环境就直接 pip install。结果包装到了全局，项目里死活 import 不到。嗯，从那以后我每次都会先检查命令行前缀。
退出虚拟环境也很简单：
deactivate如果你用 virtualenv，命令几乎一样：
# 安装 virtualenv
pip install virtualenv
# 创建虚拟环境
virtualenv myenv
# 激活和退出跟 venv 一样
source myenv/bin/activate
deactivate1.4 虚拟环境的核心逻辑
为了让你更直观地理解，我画了一张图：
看到没？每个虚拟环境都是独立的。项目A用Django 2.2，项目B用Django 4.0，全局环境里装的是Django 2.0。三个版本共存，谁也不影响谁。
1.5 避坑指南
我踩过的坑，你就不用再踩了：
- 不要把虚拟环境文件夹提交到Git仓库。它太大了，而且每个人的路径可能不同。用
requirements.txt来记录依赖就好。 - 记得在项目根目录创建虚拟环境。我见过有人把虚拟环境建在桌面，结果项目换台电脑就找不到了。
- 激活后再安装包。我曾经在没激活的情况下装了半小时的包，最后发现全装到了全局。
小技巧：创建虚拟环境后，第一时间生成 requirements.txt：
pip freeze > requirements.txt这样别人拿到你的项目，直接 pip install -r requirements.txt 就能复现环境。
好了，虚拟环境这块儿就讲这么多。说白了，它就是给你每个项目一个干净、独立的空间。别嫌麻烦，养成习惯后你会发现，这玩意儿真香。
可可精品资料库