写这篇指南的念头，源于上周帮一位朋友排查项目问题。他开发的Web服务在本地跑得好好的，部署到服务器后却频繁报错，排查了半天才发现是服务器上另一个项目的第三方库版本把共享环境里的依赖覆盖了。那一瞬间我就觉得，Python虚拟环境（venv）这种基础得不能再基础的工具，其实还有相当多的人在"能用"和"会用"之间徘徊。作为一门以灵活著称的语言，Python这一路走来一直被全局依赖的问题困扰，而venv就是目前最亲民、最稳定的隔离方案。这篇文章就把我多年实战中关于venv的使用经验、底层原理和踩坑教训一并讲透，希望能帮你在项目依赖管理上少走一些弯路。
1. 项目依赖冲突：虚拟环境要解决的最原始痛点
1.1 一次真实项目迁移：依赖地狱是怎么形成的
先从我那位朋友的经历说起。他的项目是一个基于Flask搭建的数据看板，依赖了Flask 2.x版本、某个内部封装的ORM、以及一系列数据处理库。开发阶段一切顺利，因为他的电脑上从来没装过其他Python项目，所有依赖都装在系统Python的site-packages里。到了部署阶段，服务器上已经跑着另一个使用Flask 1.x的老项目，部署脚本安装新依赖的时候，pip检测到Flask 2.x需要的某些底层库版本和老项目冲突，直接按照依赖解析结果把共享站点包里的几个库做了降级。结果就是：老项目的接口开始报错，新项目的部分功能也因为底层库版本被进一步解析而变得行为异常。
这就是典型的"依赖地狱"。在没有虚拟环境的日子里，所有项目都共享同一个系统Python环境，你升级了某个包，可能就有一批项目因此遭殃。你在破解别人的bug的同时，很可能又给别人埋下了新的雷。我自己见过太多开发者在被依赖问题折磨后转战Docker，其实很多情况下根本不需要那么重的方案，一个venv就能解决90%的困扰。
1.2 全局环境的致命缺陷：升级一个包，炸掉一片
全局Python环境的致命缺陷，本质上在于"共享状态"。当两个项目同时需要某个库，但版本要求不一致时，这个共享环境无法同时满足双方的需求。举个最贴近日常的例子：项目A需要requests的2.25.0版本，项目B需要2.28.1版本，假如你只有一个全局环境，pip只能让最终环境里出现一个版本。哪怕你对两个项目做了一堆兼容性补丁，也仍然无法保证两个项目能同时稳定运行。
另外还有一个很隐蔽的问题：你可能在某个项目里用pip install装了一个临时测试用的包，过了几个月自己都忘了。这个临时包可能通过依赖关系，在某个版本更新中引入了和项目核心依赖不兼容的底层库。这种事情我是真实遇到过的——一个莫名其妙的Django迁移报错，追查了很久才发现是半年前装的一个随手测试用的mysqlclient二进制版本作祟。如果你用的是虚拟环境，这种事情根本不会发生，因为环境是隔离的，测试完直接删掉环境就干干净净了。
1.3 虚拟环境的隔离思路：每个项目一间独立房间
虚拟环境的隔离思路，是"每个项目一间独立房间"。房间里有自己的Python解释器、自己的site-packages目录、自己的pip工具。项目A的依赖怎么升级，都影响不了项目B。
用生活化的类比来说：全局环境就像一间大宿舍，所有住户共用厨房、浴室和衣柜，一个人把自己的东西塞满了，别人就没地方放，而且互相之间还容易拿错。虚拟环境则是给每个住户单独开了一间带独立设施的小公寓，你的衣柜里有什么衣服、厨房里有什么调料，跟隔壁完全无关。你搬走的时候，把那间公寓的所有东西清走，公共区域一点都不会受影响。
venv的出现让Python项目的依赖管理有了一个"兜底"选项——无论你后续用不用Poetry、Pipenv这类更高级的工具，底层最终的隔离逻辑都是构建在venv这一层上的。所以搞懂venv，等于打牢了Python项目依赖管理的基石。
2. venv核心操作：从创建到删除的完整闭环
2.1 创建虚拟环境与Python版本选择
创建venv的命令很简单：
python -m venv myproject_env这个命令会在当前目录下生成一个myproject_env文件夹。默认情况下，它会基于当前执行命令的python解释器版本来创建环境。如果你电脑上装了多个Python版本，要特别注意这一点——你用python3.8执行这个命令，建出来的环境就是Python 3.8，不会因为你项目标签里写着"Python 3.11"就自动变成3.11。
所以创建环境前，先确认你的Python版本：
python --version如果你需要特定版本，在创建时就要指定好对应的解释器。比如我现在机器的python3指向3.10，某个老项目需要3.6，我只能用python3.6 -m venv的方式去建环境，前提是系统里装了3.6。这一步的坑很多人在刚接触时会踩——"我明明建了环境，为什么版本不对？"——先检查创建命令用的是哪个解释器，十有八九答案就出来了。
还有一个小细节：创建venv之后的目录名，不要带空格和中文。虽然现代操作系统和Python都能容忍，但后续在自动构建脚本、CI流水线、IDE配置里碰到带特殊字符的路径时，很容易出现各种古怪的编码问题。你永远不希望一个项目因为环境路径多了一个空格而莫名其妙地挂掉。
2.2 激活机制的本质：路径切换而非魔法
创建完成后的下一步是激活环境。不同操作系统的激活命令不一样：
# Windows (Cmd) myproject_env\Scripts\activate.bat # Windows (PowerShell) myproject_env\Scripts\Activate.ps1 # Linux / macOS source myproject_env/bin/activate激活之后，命令行提示符会多出(myproject_env)前缀，比如：
(myproject_env) user@host:~$这个前缀告诉你：当前shell已经进入虚拟环境。核心原理是，激活脚本修改了当前shell的PATH环境变量，把虚拟环境的bin（Windows下是Scripts）目录放到了系统目录之前。这样你在终端输入pip或python时，系统会优先找到虚拟环境内的命令，而不是全局命令。
理解这一点至关重要。激活并不是什么神奇的"状态绑定"，它只是改变了命令查找路径。所以如果你在一个已经打开的VSCode终端里激活了环境，然后又新开了一个终端窗口，新窗口并不会有(myproject_env)前缀——因为它没激活过。很多人以为激活了环境就"一劳永逸"，其实每个新的shell都需要重新激活。
有些朋友问我能不能不激活直接使用虚拟环境，当然可以。虚拟环境目录里有一个独立可执行的python，你可以直接用它的完整路径调用：
/path/to/myproject_env/bin/python -m pip install flask这种方法在某些自动化和脚本场景下非常有用，因为它不需要依赖shell的状态。不过日常开发时，还是建议用激活的方式，否则每次都要敲一长串路径，费手。
2.3 退出与删除：做对收尾，避免环境残留
退出虚拟环境的命令很简单：
deactivate执行后，命令行提示符会恢复成原来的样子。功能够简单，但有几个细节值得注意。
第一，如果你用的是PowerShell，激活脚本的执行可能会被策略拦截，这属于正常现象，不是环境坏了，我在后文的避坑部分会专门提到解决方案，这里先不展开。
第二，虚拟环境删除不需要"卸载"。想删掉一个环境，直接删除整个虚拟环境文件夹即可：
# Linux / macOS rm -rf myproject_env # Windows (PowerShell) Remove-Item -Recurse -Force myproject_env为什么不干净？因为虚拟环境目录是自包含的，它里面包着一个复制的Python解释器和一套独立的site-packages。没有向系统注册任何组件，所以直接删文件夹就是最彻底的卸载。这一点和Windows上的系统服务完全不同，反而和便携版软件类似——绿色软件，删文件夹即卸载。
第三，提醒一个很多人忽略的细节：删除环境前，最好先在环境里生成一份requirements.txt或通过pip freeze > requirements.txt导出一份依赖清单。否则你删掉环境之后，突然想起"那个项目的依赖列表我还需要一份"，可就真的没地方找了。依赖清单是这个环境的"使用说明书"，丢了就只能靠记忆。我个人的习惯是每个项目一稳定下来，就立刻固化一份requirements.txt提交到代码仓库，这算是一个低成本高回报的工程习惯。
3. venv底层原理：它到底是怎么做到的
3.1 虚拟环境目录里到底放了什么
很多人被虚拟环境这个名字吓住，觉得它是某种高级的魔法。其实，如果你打开一个虚拟环境目录，你会发现它的结构并不神秘：
myproject_env/ ├── bin/ # Linux/macOS，存放 python 可执行文件、pip、activate 脚本 │ ├── python -> /usr/bin/python3.10 │ ├── pip │ ├── activate │ ├── activate.csh │ └── activate.fish ├── include/ # 编译Python扩展时需要的一些头文件 ├── lib/ # 存放 site-packages 的目录，依赖包都装在这里 │ └── python3.10/ │ └── site-packages/ └── pyvenv.cfg # 配置文件，记录虚拟环境的基础信息在Unix系统中，bin/python通常是一个指向系统Python解释器的符号链接（symlink），而不是复制一份完整的Python二进制文件。这样做的好处是节省磁盘空间，同时能复用系统Python的底层标准库。不过，虚拟环境会有自己的site-packages目录，这正好就是"隔离"得以实现的核心所在。
在Windows系统下结构稍有不同，是Scripts目录而不是bin，解释器也通常是直接复制而不是符号链接，但核心思想是一致的：用独立的site-packages隔离项目依赖。你装一个包，它被放进lib/python3.10/site-packages，而不是全局的/usr/lib/python3.10/site-packages。
3.2 sys.prefix与site-packages的指向逻辑
Python解释器在启动时会查找自己的sys.prefix，这个前缀路径决定了标准库和第三方包的位置。如果你在全局环境里打开Python交互式命令行，输入sys.prefix，看到的路径就是系统Python的安装目录；如果你在虚拟环境里执行同样的命令，sys.prefix就会指向虚拟环境的目录。
sys.path则负责告诉解释器去哪找模块。在虚拟环境中，sys.path的第一项就是虚拟环境下的site-packages路径，而不是全局的site-packages。创建虚拟环境时，venv会生成一个pyvenv.cfg文件，里面标记了指向基础系统Python的位置，这就是venv确定隔离逻辑的"配置文件"。
用Python代码验证一下这个过程，非常直观：
import sys print(sys.prefix) print(sys.executable)在虚拟环境里运行，第一行输出的是虚拟环境的路径；第二行输出的是虚拟环境bin目录下的python可执行文件路径。这就是最直接的证据：你的代码正在虚拟环境里执行，用的是虚拟环境里的解释器和独立的包目录。
3.3 pip视角下的site-packages：隔离的"最后一公里"
你以为虚拟环境中的pip是另一个独立的工具？其实它和全局的pip非常像——在虚拟环境中执行pip --version时，它的输出会明确告诉你"用的是哪个解释器的pip"和"包会装到哪个目录"。
(myproject_env) $ pip --version pip 23.2.1 from /path/to/myproject_env/lib/python3.10/site-packages/pip (python 3.10)看到没有？pip 的源码位置也指向虚拟环境路径。这说明在虚拟环境中执行pip install，装的包会落到虚拟环境的site-packages里，不会污染全局环境。这才是"隔离"的最后一公里。如果你发现pip --version显示的路径还是全局的路径，那多半是激活失败或者激活后被覆盖了，这个排查思路也很实用，后文会展开讲。
4. 与多版本Python管理的配合：venv不解决的事
4.1 某项目要Python 3.6，某项目要3.11：版本冲突怎么办
venv虽然能隔离第三方库依赖，但它有一个天然的边界：它无法帮你安装不同版本的Python解释器。你想用venv建一个Python 3.6的环境，前提是你系统里至少装过Python 3.6。如果你的机器上只有Python 3.11，那你就没法用venv直接创建3.6的环境。
现实往往比理想复杂得多。我身边有不少人维护着多个项目，有的是老系统的维护任务，必须在Python 3.6下运行；有的是新项目，已经使用Python 3.11的新语法特性。系统里全局只装一个Python版本时，这种需求就变得棘手。
此时vevn需要一个搭档——一个Python版本管理器。市面上常见的方案有几个，这里先提一个主流思路：如果你用的是macOS或Linux，pyenv是管理多版本Python最顺手的工具之一，它可以编译或下载多个Python版本，并在系统层面随时切换当前使用的默认版本。在Windows上，则通常使用官方Python安装器来安装多个版本，然后通过类似py启动器的选择器来切换。
4.2 pyenv管理多版本Python的正确姿势
pyenv的核心概念很直观：它在本目录下维护一组已经安装的不同版本的Python解释器。当你执行pyenv global 3.10后，系统的python命令就指向Python 3.10；执行pyenv global 3.6.8后，python命令又变成Python 3.6.8。
安装pyenv后，典型的操作流程是：
# 查看可安装的版本 pyenv install --list # 安装指定版本 pyenv install 3.9.16 # 查看已安装的版本 pyenv versions # 为当前目录设置本地版本 pyenv local 3.9.16有了pyenv，你就可以针对不同项目设置不同的Python版本，然后在每个项目目录下使用venv创建虚拟环境。这样组合起来，项目才真正做到"版本与依赖双重隔离"。
有一点需要强调，pyenv和venv是两个层面的工具，不要把它们混为一谈。pyenv解决的是"用哪个解释器版本"，venv解决的是"在这个解释器版本下，项目依赖如何隔离"。两者配合才能发挥最大效果。
4.3 一套完整的多版本&多依赖工作流
根据我个人多年折腾下来的经验，给你一套可以直接照搬的组合方案。
第一步，用pyenv为项目设置Python版本：
cd myproject pyenv local 3.10.12这会在当前目录生成一个.python-version的文件。只要在这个目录下打开终端，python命令都会自动指向3.10.12版本。进入该目录的Shell时会自动加载这个配置，无需重复切换。
第二步，创建venv虚拟环境：
python -m venv .venv这里我故意把环境名取为.venv，而不是myproject_env。因为以点开头的目录是隐藏目录，不会让你的项目根目录看起来乱糟糟的，而且VSCode、PyCharm这些IDE都能自动识别.venv这个约定俗成的名称。这个细节看似微小，但如果你维护的项目多了，每个项目根目录下整整齐齐的只有一个.python-version和一个.venv，看起来会舒服很多。
第三步，激活环境并安装依赖：
source .venv/bin/activate pip install -r requirements.txt第四步，开发完成之后，导出依赖清单：
pip freeze > requirements.txt这套工作流无论是个人项目还是团队协作，都足够清晰。
5. venv和conda、poetry、pipenv：到底该怎么选
5.1 四者的定位差异
在Python社区里，虚拟环境的解决方案不止venv一种，我经常被问到这个问题：我该用conda还是venv？该用pipenv还是poetry？
先列个表格，四者在定位上的核心差异一目了然。
| 工具 | 依赖隔离机制 | Python版本管理 | 主要使用场景 | 额外能力 |
|---|---|---|---|---|
| venv | 独立的site-packages | 不支持，依赖系统已装的版本 | 绝大多数Python项目 | 轻量、Python标准库自带 |
| conda | 独立的环境目录 | 自带Python版本管理 | 数据科学、科学计算领域 | 管理非Python依赖（如C库、CUDA等） |
| pipenv | 底层依赖venv | 间接支持，基于Pipfile的锁文件 | 追求简单依赖管理的Web项目 | 自动管理依赖树，锁文件可复现 |
| poetry | 底层依赖venv | 间接支持，基于pyproject.toml | 现代Python项目，尤其是发布为库的项目 | 打包发布能力、依赖解析更精确 |
从这张表可以看得很清楚：venv是纯粹的"环境隔离工具"，它解决并且只解决依赖隔离这一个问题；conda是重量级的"环境+包管理器"，它的环境隔离做得很不错，Python版本管理和非Python依赖（比如某些只有conda渠道才有预编译包的C库）管理能力也很强，但它的代价是环境体积大、整体速度略慢；pipenv和poetry都是在venv之上再做了一层依赖管理和锁定，解决"这个项目到底装了哪些包、什么版本、依赖关系如何记录"的问题。
5.2 从实际需求出发的选型建议
选型建议其实非常简单，关键就看你的项目场景。
如果你是做Web开发、脚本工具、数据处理等绝大多数常规Python项目，我的建议是：直接使用venv + requirements.txt。它足够轻量，没有额外的学习成本，任何一个Python开发者打开你的项目都能立刻上手。团队协作的时候，也不需要每个人都安装Poetry或Pipenv。
如果你主要工作是数据科学、机器学习，需要大量涉及NumPy、SciPy、PyTorch这类依赖底层C库的包，conda更合适。conda的channel上有很多编译好的预编译包，能避免你在本地去折腾C++编译器。
如果你是在进行一个长期维护的Python库项目，并且很在意可复现性和版本精确性，poetry值得尝试。它的pyproject.toml和poetry.lock锁定机制在工程化方面确实做得更整洁。
如果你就是不想操心虚拟环境激活这件事，pipenv能在进入项目目录时自动加载虚拟环境并配好依赖，比较适合喜欢"零切换"体验的人。
我的个人偏好是：能用venv解决的问题，就不要引入额外的工具。很多团队引入Poetry后被锁文件冲突、构建流程问题搞得焦头烂额，反而用一个朴素的requirements.txt配venv从没出过事。把复杂留给真正有复杂需求的地方，这不丢人。
6. 实际使用中那些说不清的坑与对应解法
6.1 PowerShell激活报错：执行策略导致的假故障
Windows下使用PowerShell时，运行myproject_env\Scripts\Activate.ps1经常会报一条红色错误，内容大致是"因为在此系统上禁止运行脚本"。
这不是venv出了问题，而是PowerShell的安全执行策略在拦截未签名的脚本。解决方式有两种。
一种是临时修改执行策略，仅对当前用户生效：
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser执行后再次激活即可。RemoteSigned策略允许运行本机创建的脚本和由可信发布者签名的远程脚本，对个人开发者来说够用且不至于把安全防线全拆掉。
另一种是绕过PowerShell策略，直接使用系统的cmd命令行来激活虚拟环境：
myproject_env\Scripts\activate.bat在cmd下，这个脚本通常没有任何限制，能直接激活。
如果你在VSCode的集成终端里遇到了这个问题，还要注意VSCode的默认终端类型。如果默认是PowerShell且激活报错，可以直接在终端右侧下拉菜单把默认终端切换为"命令提示符"，或在settings.json里设置：
"terminal.integrated.defaultProfile.windows": "Command Prompt"这算是一个比较省心的改动。
6.2 明明激活了环境，pip却装到了全局
这也是一个高频迷思。当你在虚拟环境里执行which python或where python，显示的路径确实是虚拟环境内的路径；但是执行which pip，显示的却是全局的pip路径，甚至安装的包跑到了全局的site-packages里。
这个问题的根源一般有两种。
第一种：创建虚拟环境时，环境里没有完整地生成pip工具。某些Linux发行版里，Python安装时没有附带pip，而且ensurepip模块缺失。这时候可以用python -m ensurepip --upgrade来引导补齐pip。
第二种：你虽然激活了虚拟环境，但全局环境里设置了某些别名或PATH优先级，导致pip被解析成了全局的。通常我先看一眼激活后的PATH环境变量：
echo $PATH虚拟环境激活后，第一项应该是虚拟环境的bin或Scripts目录。如果排在第一位的不是虚拟环境路径，那就需要检查shell配置文件（比如.bashrc或.zshrc）里有没有把全局pip的路径硬编码到PATH前面。
定位命令更稳妥的办法，是无论是否激活环境，都用python -m pip来执行安装，这样pip永远跟着当前解释器走，不会出现分道扬镳的情况：
python -m pip install requests我个人的习惯是几乎所有情况下都使用python -m pip而不是裸pip，这个习惯让我少踩了许多环境串台的坑。
6.3 明明在环境里装了包，却import不到
这个问题比pip装错环境更隐蔽，一般有几种可能。
第一种：你当前运行的Python解释器并不在虚拟环境内。很多人用IDE的时候，没有把IDE配置的Python解释器指向虚拟环境内的解释器，导致虽然终端显示已激活，但IDE执行脚本时仍然使用全局Python。解决方式是手动把VSCode的Python解释器路径设置到.venv/bin/python，或者在PyCharm的Settings里为项目添加虚拟环境解释器。
第二种：你安装的包以--user模式安装了。如果你在虚拟环境里执行pip install --user requests，pip通常会警告"将包安装到用户目录而不是虚拟环境"，这个包根本不会进入虚拟环境的site-packages。执行pip install时，不要额外加--user参数。
第三种：命名空间包带来的困扰。某些大规模包拆成了多个子包，安装其中的某个子包后，在site-packages里找不到同名的顶级模块，导致import失败。这个相对冷门，遇到时可以用pip show来确认包实际安装到了哪个路径。
现象出来后，最快的一条排查链路是：
- 确认激活后的解释器路径：
which python； - 确认
sys.path前几项：python -c "import sys; print(sys.path)"； - 确认包的安装路径：
pip show 包名，查看Location字段。
这三步走下来，大多数"找不到包"的问题都能被定位到具体环节。
6.4 requirements的依赖锁定：别把"能用"当成"可复现"
pip freeze > requirements.txt是很多团队锁依赖清单的常用方式。它的输出非常全，会把环境里的所有包和版本都记录进去，包括依赖树的中间层。这在做项目复现时很有用，但也有一个隐患：pip freeze的输出格式依赖于当前pip版本对依赖树的解析结果，如果你在不同的时间点分别执行pip freeze，同样的环境下可能输出不同的顺序，甚至因为pip解析行为的不同而出现细微差异。
所以更稳妥的做法是，核心依赖用requirements.in或直接在requirements.txt里手写顶层的依赖约束，辅助依赖通过加注释来补充说明。比如：
flask==2.3.3 requests==2.31.0 # 以下为间接依赖（由pip自动解析，记录时保留指定版本） certifi==2023.7.22 charset-normalizer==3.2.0 idna==3.4 urllib3==2.0.4这样做的好处是，主依赖变动时你能知道是什么导致的，不透明的间接依赖版本变化也不会悄悄溜进来。如果你需要严格的可复现构建，pip-tools里的pip-compile是比裸pip freeze更专业的方案，它会从顶层依赖出发，解析并生成一份结构清晰的分层锁文件。
依赖管理这件事，宁可一开始多花十分钟，也不要等到部署环境因为一点点版本差异跑不起来时再回头查。
6.5 离线环境下的venv迁移策略
有些时候目标部署机器无法访问公网，不能直接pip install安装依赖。这个场景在银行、电力等内部网络中很常见。我常用的做法是，把要安装的依赖包下载成wheel文件，然后拷贝到目标机器上安装。
在有网的环境里执行：
pip download -r requirements.txt -d ./wheelhouse然后把整个wheelhouse目录拷贝到目标机器，离线环境里执行：
pip install --no-index --find-links=./wheelhouse -r requirements.txt这可以保证目标机器不需要访问任何外部网络。如果你想要的是更加一体的方案，还可以考虑把你建好的整个虚拟环境用压缩包打包，拷贝到目标机器上解压直接使用。但要注意，虚拟环境和系统Python解释器版本、以及某些编译型依赖的ABI兼容性息息相关，跨平台或者跨Python版本直接搬运虚拟环境并不总是安全的。最稳妥的做法还是在目标机器上新建venv，再从wheelhouse安装依赖。
6.6 环境变量与C扩展：venv解决不了的非Python依赖
venv解决的是Python层的依赖隔离，但它并不能隔离所有系统级依赖。比如某个项目需要libssl.so.1.1，而另一个项目需要libssl.so.3，这类系统动态库的版本冲突已经不是venv能够处理的范围。
遇到这种问题，可以先退一步评估：是不是项目的Python包版本过老或过新导致的系统库兼容性问题？能通过换包版本解决就先换版本。如果确实改不了，那就只能考虑conda（它可以管理C库软件包）或容器化方案（比如Docker）来把整个运行时环境一起隔离。这也是我经常给团队建议的一个原则：你的隔离需求有多大，就选多大的隔离工具。venv管Python层，conda再管C库层，Docker管操作系统层，别让venv去承担它能力之外的活儿。
7. 关于虚拟环境更进一步的思考
7.1 现代搞Project：用工具链替代手工记忆
我见过不少开发者到现在还在用"先装包、后写requirements"这种流程，导致requirements.txt里包很多但实际代码根本用不到那么多。更现代的做法是：先写清楚项目中真正用到的包，然后再安装。
这里个人比较推荐的思路是：把项目的核心依赖写在项目里的一份配置中，配合工具自动解析依赖关系。比如pip-tools或poetry这类方案，它们不依赖你的记忆，而是从你的代码和已声明的顶层依赖出发，生成锁文件。这样既不会漏包，也不会装一堆无用的包。
7.2 从开发环境到生产部署：venv在中间环节的意义
venv不只是开发期的事。在生产部署场景中，合理的流程一般是：在CI阶段创建干净的venv，按锁文件安装依赖，随后运行测试，确保一切通过之后，再把整个虚拟环境的依赖镜像或wheelhouse带到生产服务器。
如果你的项目是用Docker发布，那么venv也依然扮演角色：在Docker构建时先建venv再安装依赖，能利用Docker的缓存机制让多阶段构建的产物更干净。依赖隔离这件事不是"开发完就不管了"，而应该贯穿整个交付链路。
7.3 我的个人习惯总结
如果你要我给一个最小可行方案，我会这么说：每个项目从第一天就创建并坚持使用venv，环境目录统一叫.venv，并且加入.gitignore。依赖清单做到生成后提交、变更后及时更新。包管理和环境管理是两个维度的问题，前者用工具解决，后者用venv解决，千万不要混为一谈。
如果更进一步，我会建议团队把手动操作环境和依赖的方式逐渐改成脚本化。比如项目根目录放一个setup.sh，里面自动执行版本检查和环境初始化。这样新同事clone完项目，跑一条命令就能进入开发状态，对任何新成员来说都友好很多。把工具链做到"傻瓜化"，才是工程能力的最好体现。
