你可能也经历过这种场景照着教程往全局环境里装了一堆 Python 包然后打开另一个项目突然发现某个库从能用变成了报错。查了半天不是代码写错了是依赖打架了。Python 虚拟环境venv就是为了根治这件事而生的——它把每个项目的依赖隔离在各自独立的空间里互不干扰。这篇指南会从原理讲到实操再聊到我日常踩过的坑和工具选型无论你刚接触 Python还是已经在项目里挣扎过一段时间都能找到可以直接拿去用的东西。1. 项目依赖的脏乱差为什么每个Python项目都需要自己的隔离空间1.1 依赖冲突是怎么毁掉一个项目的先讲一个我真实遇到过的案例。前几年我维护一个自动化脚本里面用了requests的 2.24 版本跑得好好的。后来接手另一个爬虫项目按提示装了某个第三方库这个库传递依赖把requests升到了 2.32。结果回到原来的脚本一执行直接抛出InvalidHeader之类的异常。查了很久才发现问题根本不在代码而是全局环境里的包被悄悄换掉了。这类事情在 Python 开发里太常见了。很多库的 API 并不同时代完全兼容小版本升级也可能带来破坏性变化。如果没有隔离你今天装的包会影响昨天写的项目明天的项目又会反过来污染今天的环境。时间一长你的全局site-packages第三方包的安装目录就像一个没人整理的大仓库里面堆满了各种版本的包鬼知道哪个项目依赖哪个。1.2 装到我电脑上就好了的复现难题另一种痛点是复现。国外程序员常爱开玩笑说 works on my machine在我电脑上能跑这背后其实就是环境不一致的问题。你项目里没列明依赖版本队友拉下去代码按照文档装包装出来的版本和你本机差个一两级同一个接口可能就有完全不同的行为。还有更实际的问题你把项目部署到服务器上要是不小心把包装到了系统自带 Python 里一旦操作系统升级、系统包被替换你的服务可能莫名其妙就挂了。而虚拟环境能保证项目 A 装了什么包、什么版本和项目 B 完全隔离你交付项目时一份requirements.txt就能让任何人在三分钟内复现出和你一样的环境。1.3 虚拟环境不是什么高深魔法就是一个独立工位很多人听到虚拟环境四个字总觉得是个很玄的东西。其实你完全可以把它想象成办公室里的独立工位全局环境是整个大办公室大家共用一个书桌site-packages谁放的东西都可能被别人拿走或弄脏而 venv 就是给你单独安排了一张桌子你的书、你的文具都放在自己抽屉里别人要用另开一张桌子互不干扰。这才是我写这篇指南的原因。venv 作为 Python 官方标准库自带的能力从 Python 3.3 开始内置3.5 以后成为正式推荐不需要额外装任何东西几乎零成本就能解决上面这一堆痛苦。你只需要学会几条命令。2. venv 的隔离原理它不是虚拟机而是一套精巧的环境变量把戏2.1 venv 目录里到底有什么要真正掌握 venv最好不要只会敲命令得先搞懂它到底在背后干了什么。当你在某个目录下执行python -m venv myenv后会生成一个myenv文件夹里面结构大概是这样以 Linux/macOS 为例myenv/ ├── bin/ │ ├── activate │ ├── pip │ ├── pip3 │ ├── python │ └── ... ├── include/ ├── lib/ │ └── python3.x/ │ └── site-packages/ └── pyvenv.cfgWindows 下结构略有差异主要区别是脚本目录叫Scripts里面有activate.bat、Activate.ps1、pip.exe等库目录叫Lib。pyvenv.cfg是环境配置文件里面记录了home指向你创建这个环境时用的 Python 解释器位置、include-system-site-packages是否允许访问全局包等关键信息。注意一个关键点venv 里的python在 Linux/macOS 下其实是一个符号链接指向你系统的 Python 解释器Windows 下则是拷贝了几个必要的可执行文件。所以 venv 并不会把整个 Python 解释器复制一份它创建的更像是一个虚拟的解释器外壳。2.2 激活和不激活的区别PATH 顺序决定一切那为什么在终端里执行source myenv/bin/activate之后提示符前会出现(myenv)而且python、pip都指向了环境里的版本核心秘密在环境变量PATH。激活脚本做的事情本质就是把它所在目录myenv/bin或myenv\Scripts插到了PATH的最前面# 激活前 $ which python /usr/bin/python # 激活后 $ which python /home/yourname/myenv/bin/python因为系统在执行命令时从上到下扫描PATHmyenv/bin排在了/usr/bin前面所以这次你敲python用的是环境里的解释器敲pip也是环境里的pip。这个环境里的python会通过pyvenv.cfg知道自己属于哪个虚拟环境并默认把第三方包装到myenv/lib/python3.x/site-packages不会污染全局。而当虚拟环境被激活时PYTHONHOME这类变量也会被清空确保解释器不会错误地去加载系统目录里的库。2.3 为什么 venv 创建得这么快、占空间这么小正因为 venv 不是真正复制一份完整的 PythonLinux/macOS 下甚至不复制解释器本体所以创建速度极快通常在几秒内完成占用的磁盘空间也只有几 MB 到几十 MB。这也是它和后面要讲的 conda 最大的区别之一——conda 创建的独立环境会自带一套完整的 Python 运行时和二进制依赖体量往往大得多。明白了这个原理你就能理解很多坑的来源了因为 venv 依赖你创建它时指定的那个基础解释器所以如果你删掉了系统里的 Python或者把 venv 文件夹拷贝到一台 Python 版本不同的机器上环境就有很大概率废掉。这是后话第 5 章我会展开讲。3. 从创建到删除venv 生命周期全流程实操手册3.1 创建环境python -m venv 背后的细节首先确认你的 Python 版本够新。我建议使用 Python 3.7 以上因为新版 venv 的体验和稳定性都好不少。创建方式非常简单# 在项目根目录下执行 python -m venv venv这里第一个python是你当前全局环境里的解释器-m venv意思是调用标准库里的 venv 模块最后一个venv是环境文件夹的名字。很多人习惯把环境文件夹命名为.venv前面加个点隐藏目录因为 VSCode、PyCharm 等工具会默认识别这个名字git 也更方便忽略它。如果你本机装了多个 Python 版本想用某个特定版本创建环境可以写完整python3.11 -m venv venv311创建时还可以加参数最常用的是这两个--system-site-packages让虚拟环境允许访问全局装的第三方包。默认不开启因为我们的目的就是隔离但如果你全局已经有一堆常用的重型库比如 numpy又不介意共享开启可以省不少安装时间。--copies强制用复制而非符号链接的方式创建解释器Windows 默认就是复制Linux/macOS 下有特殊需求比如要把环境拷走才用到。3.2 激活环境三个平台的正确姿势激活命令在 Windows 和 Linux/macOS 下不一样我列个表格方便对照平台激活命令停用命令Windows CMDvenv\Scripts\activate.batdeactivateWindows PowerShellvenv\Scripts\Activate.ps1deactivatemacOS / Linux bashsource venv/bin/activatedeactivate激活成功后你会在终端提示符最前面看到(venv)这就是最直观的确认方式。如果没看到说明激活失败或者你根本还在外层。接下来可以进一步验证# Linux/macOS which python # 输出应该类似/path/to/your/project/venv/bin/python # Windows where python # 输出应该会包含你的 venv\Scripts\python.exe提示在 Windows 上如果你用 Git Bash激活文件路径是venv/Scripts/activate正斜杠也能用其他 shell 同理。关键是别敲错文件名。3.3 安装、导出与复现依赖环境激活后安装包用pip就行pip install requests pip install -r requirements.txt装完后你可以用pip list查看当前环境里所有安装的包。注意因为隔离你全局环境里以前装过的包在这个环境里都是不存在的需要重新安装。这是很多人刚接触虚拟环境时觉得麻烦的点但其实这正是它对你项目负责的表现。项目依赖整理推荐这么做# 导出当前环境的所有包及精确版本号 pip freeze requirements.txtrequirements.txt的格式很简单就是包名版本号比如requests2.32.3 flask3.0.0另外一台机器上只需要python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install -r requirements.txt三步走完环境完全复现再也不会出现我这个包是有的啊这种困扰。一个细节pip freeze会把当前环境里所有包都导出来如果有些包是某个库的传递依赖一般也会一起列出直接提交完全没问题。要是环境里装过 pip 之外的包管理工具残留建议先手动清扫一下再 freeze。3.4 退出与彻底删除一键清零的快乐不需要虚拟环境了直接执行deactivate回到全局环境。整个文件夹比如venv或.venv直接删除即可——这就是虚拟环境最爽的地方它是完全独立于系统的删了就是删了不会对全局 Python 产生任何残留影响。我也见过一些人用完后不删项目堆了一堆后积累了大量环境文件夹每个几百 MB。建议在项目生命周期结束后及时清理尤其做数据科学的朋友环境里动辄几个 GB 的重型库留着挺占磁盘的。4. 在真实开发环境里用好 venv编辑器集成与多版本 Python 并存4.1 VSCode 里选对解释器少走一半弯路VSCode 是目前最主流的 Python 编辑器之一。很多新手在 VSCode 里遇到明明激活了虚拟环境但运行时还是用全局 Python的问题根本原因往往是VSCode 里跑的 Python 插件和终端里的环境是两回事。在 VSCode 里你按CtrlShiftP打开命令面板输入Python: Select Interpreter选择你的venv里的 Python 解释器路径通常显示为./venv/bin/python或venv\Scripts\python.exe。选对之后插件会用这个解释器跑代码。但终端Terminal里的激活又是独立的——如果终端里没激活虚拟环境终端直接跑python还是全局的。解决方案有两种一是在终端里手动激活第 3.2 节的方法二是让 VSCode 自动激活。新版 VSCode Python 插件在你打开带.venv文件夹的项目时会自动检测并提示选择解释器选了之后新建的终端也会自动进入该环境。如果你的版本不支持可以设置python.terminal.activateEnvironment: true这个配置的意思是当终端启动时自动执行虚拟环境的激活脚本。我可以明确说配置好这一步之后你在 VSCode 里的开发体验会顺畅很多。4.2 PyCharm 的虚拟环境配置与注意事项PyCharm 对 venv 的支持更加一体化。新建项目时左侧的New environment using下拉框选VirtualenvPyCharm 会自动帮你创建venv目录并且在终端里自动激活。如果项目已经建好了打开File - Settings - Project: xxx - Python Interpreter点齿轮选Add选Existing environment然后指定 venv 里的 python 路径即可。这里我提一个容易忽略的点PyCharm 里跑脚本用的解释器是Project Interpreter里选的和 PyCharm 自带的 Terminal 里的环境可能不一致。所以如果你在 PyCharm 自带的终端里敲pip install要确保终端里的环境和你 Run 脚本的解释器是同一个。经验做法是建项目时让 PyCharm 生成 venv之后统一在终端里安装包并且在右下角状态栏确认解释器路径。4.3 多版本 Python 并存pyenv 是 venv 的最佳搭档很多人问我电脑上既有 Python 3.8 又有 Python 3.11怎么给不同项目匹配不同版本venv 本身只负责隔离包不负责管理解释器版本——但你可以先用版本管理工具选好解释器再用它创建 venv。最常用的是pyenvmacOS/Linux 下很流行。流程大概是pyenv install 3.11.7 pyenv local 3.11.7 # 在当前项目目录锁定 Python 版本 python -m venv venv # 此时创建的环境就是基于 3.11.7 的Windows 用户则常使用py这个官方启动器。安装多个 Python 版本后可以用py -3.11 -m venv venv311把解释器选择和依赖隔离两个问题分开处理各管好各的项目的可复现性就大幅提升。顺带说一句Python 3.3 之前流行的virtualenv和现在的标准库venv核心逻辑相似区别在于 virtualenv 速度更快、兼容更老的 Python、还支持环境搬迁等高级操作。如果不是被老项目绑定直接用python -m venv就够了它是官方现在推荐的正统姿势。5. 我在 venv 里踩过的坑排查链路与避坑清单5.1 现象一pip install 明明激活了还是装到全局这是出现频率最高的问题而且排查起来很有迷惑性。你执行了source venv/bin/activate提示符也出现了(venv)但运行pip install xxx之后在全局的site-packages里居然能看到它。正确的排查链路应该是先确认which pipWindows 是where pip看它是否指向 venv 目录。如果指向的是/usr/bin/pip或~/.local/bin/pip说明pip没有走虚拟环境。然后看echo $PATH检查 venv 目录是否排在前面。检查环境变量里有没有PIP_REQUIRE_VIRTUALENV有的配置会强制 pip 在虚拟环境外拒绝工作但也有版本会自动绕过。我遇到这类问题多数情况是用户同时装了 pipx、conda 或者有 shell 别名alias pip某个全局 pip导致 PATH 顺序被干扰。还有一种隐蔽情况在 Windows 下从 cmd 启动的终端激活了但你在 Git Bash 里跑 pip两条命令各自关联不同的环境检测逻辑。排查时先统一终端再一次性清掉 PATH 里的干扰项最可靠。5.2 现象二PowerShell 禁止运行激活脚本Windows 上首次运行venv\Scripts\Activate.ps1时经常报错无法加载文件 ...\Activate.ps1因为在此系统上禁止运行脚本这不是 venv 的问题而是 Windows PowerShell 默认执行策略是Restricted禁止运行任何 .ps1 脚本。解决办法有两种临时允许当前会话执行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process。永久改当前用户Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser。如果你不想动 PowerShell 策略直接改用 CMDvenv\Scripts\activate.bat或 Git Bashvenv/Scripts/activate就行这两种方式不涉及 .ps1 脚本同样能激活。5.3 现象三venv 里 import 不到系统里明明有的包很多人创建 venv 后惊奇地发现之前全局已经装好的 numpy、pandas在虚拟环境里突然 import 不到了——这是虚拟环境的本质不是 bug。默认情况下 venv 完全不读全局的site-packages每个环境从零开始装包。如果你确实希望新环境可以读取全局的第三方包创建时加上参数python -m venv --system-site-packages venv不过我的建议是如果项目需要 numpy 这类大型包直接在这个 venv 里装一份就好。因为全局包版本可能和你项目依赖冲突既然用了虚拟环境就别委屈求全干净才是它的价值。5.4 现象四整个 venv 文件夹换个机器就废了虚拟环境看似是一个文件夹打包就能带走实际上并不完全可移植。原因我在第 2.3 节说过了Linux/macOS 下 venv 里的python是指向创建它时那个解释器的符号链接而且pyvenv.cfg里的home字段记录的是本机 Python 的绝对路径。你把 venv 文件夹拷到另一台机器链接大概率指向不存在或版本不对的路径那个环境基本就废了。正确做法是项目目录只提交代码和requirements.txt在每台机器上重新创建 venv 并安装依赖。如果你实在想做一个可移植环境用virtualenv --relocatable或者直接改用 conda 环境甚至是 Docker 镜像都会有更好的效果——但那些就是另一个话题了。6. 从 venv 到更现代的依赖管理工具对比与选型建议6.1 venv、virtualenv、conda、poetry、uv谁在什么场合适用很多工具都提供虚拟环境能力但它们解决的问题各有侧重。我把常用方案整理成一个表工具本质优势痛点适合场景venvPython 标准库模块零依赖、轻量、官方维护仅管理 Python 包不管理解释器版本绝大多数普通项目团队协作最通用virtualenv第三方工具兼容老 Python、创建快、支持复制重定位需要额外安装逐渐被 venv 取代老版本 Python 项目conda跨语言的包环境管理能装二进制库如 C 扩展、CUDA、管理非 Python 包体积大、默认源慢数据科学、机器学习项目pipenvpip venv 封装同时管理依赖和虚拟环境生成 Pipfile性能一般依赖解析速度慢追求一键复现的应用开发poetry完整依赖管理打包现代 pyproject.toml 标准化、锁定精确版本学习曲线稍高发布 PyPI 包、复杂依赖的 Python 库uvRust 写的极速包管理创建环境和装包速度极快兼容 pip/PyPI相对年轻生态还在迭代新项目,想要极速体验这些工具并不是非此即彼的关系。我自己的经验是90% 的日常项目venv pip requirements.txt就够了它简单、通用、人人都懂。一旦项目里有复杂的分支环境、多语言依赖比如 Python 调 C 库或者想省掉手动管理 pip 的琐碎才升级到 conda 或 poetry。6.2 我的选型策略小项目、大项目、数据科学各怎么选给一个相对直接的建议脚本或轻量应用直接用python -m venv venv激活后 pip 安装导出requirements.txt。这一条适用于 90% 的场景步骤少出错概率也最低。团队协作、需要严格锁定版本用 poetry 或 uv。前者生态成熟pyproject.toml 能通过 lock 文件精确到每个传递依赖的版本后者如果你受够了 poetry 慢吞吞的解析值得尝试体验相当惊艳。机器学习/数据科学如果你跑的是 GPU 训练、需要 CUDA 环境、TensorFlow/PyTorch 一堆二进制依赖conda 真香因为它能把 CUDA、cudnn 这类非 Python 依赖也管起来。但项目足够标准时venv pip 也够用。不想折腾环境只想跑通代码直接用uv或pipenv让工具帮你自动创建和管理虚拟环境省去手动激活的步骤。说到底虚拟环境是解决问题的不是制造问题的。用最顺手的那套方案持续保持一个项目一个环境的习惯你会发现 Python 项目的可维护性提升一大截。最后分享一个这几年过来我最深刻的体会环境越干净排查问题的时间越少。曾经我花了一整晚找一个随机出现的报错最后发现是全局环境被另一个项目装了一个旧版本的库——从那天起我给每个项目建.venv就没再断过。升级系统 Python 前先看一眼你手里的项目环境是否还在正常转换新电脑或迁移环境时宁可重新pip install -r requirements.txt也别复制那个venv文件夹。这些都成了我刻进本能的操作习惯也希望你从这篇指南开始养成属于你自己的那套流程。 
长河君 · 2026/10/7 21:56:12 · 阅读 1.2k Python虚拟环境venv实战指南：从原理到最佳实践
你可能也经历过这种场景照着教程往全局环境里装了一堆 Python 包然后打开另一个项目突然发现某个库从能用变成了报错。查了半天不是代码写错了是依赖打架了。Python 虚拟环境venv就是为了根治这件事而生的——它把每个项目的依赖隔离在各自独立的空间里互不干扰。这篇指南会从原理讲到实操再聊到我日常踩过的坑和工具选型无论你刚接触 Python还是已经在项目里挣扎过一段时间都能找到可以直接拿去用的东西。1. 项目依赖的脏乱差为什么每个Python项目都需要自己的隔离空间1.1 依赖冲突是怎么毁掉一个项目的先讲一个我真实遇到过的案例。前几年我维护一个自动化脚本里面用了requests的 2.24 版本跑得好好的。后来接手另一个爬虫项目按提示装了某个第三方库这个库传递依赖把requests升到了 2.32。结果回到原来的脚本一执行直接抛出InvalidHeader之类的异常。查了很久才发现问题根本不在代码而是全局环境里的包被悄悄换掉了。这类事情在 Python 开发里太常见了。很多库的 API 并不同时代完全兼容小版本升级也可能带来破坏性变化。如果没有隔离你今天装的包会影响昨天写的项目明天的项目又会反过来污染今天的环境。时间一长你的全局site-packages第三方包的安装目录就像一个没人整理的大仓库里面堆满了各种版本的包鬼知道哪个项目依赖哪个。1.2 装到我电脑上就好了的复现难题另一种痛点是复现。国外程序员常爱开玩笑说 works on my machine在我电脑上能跑这背后其实就是环境不一致的问题。你项目里没列明依赖版本队友拉下去代码按照文档装包装出来的版本和你本机差个一两级同一个接口可能就有完全不同的行为。还有更实际的问题你把项目部署到服务器上要是不小心把包装到了系统自带 Python 里一旦操作系统升级、系统包被替换你的服务可能莫名其妙就挂了。而虚拟环境能保证项目 A 装了什么包、什么版本和项目 B 完全隔离你交付项目时一份requirements.txt就能让任何人在三分钟内复现出和你一样的环境。1.3 虚拟环境不是什么高深魔法就是一个独立工位很多人听到虚拟环境四个字总觉得是个很玄的东西。其实你完全可以把它想象成办公室里的独立工位全局环境是整个大办公室大家共用一个书桌site-packages谁放的东西都可能被别人拿走或弄脏而 venv 就是给你单独安排了一张桌子你的书、你的文具都放在自己抽屉里别人要用另开一张桌子互不干扰。这才是我写这篇指南的原因。venv 作为 Python 官方标准库自带的能力从 Python 3.3 开始内置3.5 以后成为正式推荐不需要额外装任何东西几乎零成本就能解决上面这一堆痛苦。你只需要学会几条命令。2. venv 的隔离原理它不是虚拟机而是一套精巧的环境变量把戏2.1 venv 目录里到底有什么要真正掌握 venv最好不要只会敲命令得先搞懂它到底在背后干了什么。当你在某个目录下执行python -m venv myenv后会生成一个myenv文件夹里面结构大概是这样以 Linux/macOS 为例myenv/ ├── bin/ │ ├── activate │ ├── pip │ ├── pip3 │ ├── python │ └── ... ├── include/ ├── lib/ │ └── python3.x/ │ └── site-packages/ └── pyvenv.cfgWindows 下结构略有差异主要区别是脚本目录叫Scripts里面有activate.bat、Activate.ps1、pip.exe等库目录叫Lib。pyvenv.cfg是环境配置文件里面记录了home指向你创建这个环境时用的 Python 解释器位置、include-system-site-packages是否允许访问全局包等关键信息。注意一个关键点venv 里的python在 Linux/macOS 下其实是一个符号链接指向你系统的 Python 解释器Windows 下则是拷贝了几个必要的可执行文件。所以 venv 并不会把整个 Python 解释器复制一份它创建的更像是一个虚拟的解释器外壳。2.2 激活和不激活的区别PATH 顺序决定一切那为什么在终端里执行source myenv/bin/activate之后提示符前会出现(myenv)而且python、pip都指向了环境里的版本核心秘密在环境变量PATH。激活脚本做的事情本质就是把它所在目录myenv/bin或myenv\Scripts插到了PATH的最前面# 激活前 $ which python /usr/bin/python # 激活后 $ which python /home/yourname/myenv/bin/python因为系统在执行命令时从上到下扫描PATHmyenv/bin排在了/usr/bin前面所以这次你敲python用的是环境里的解释器敲pip也是环境里的pip。这个环境里的python会通过pyvenv.cfg知道自己属于哪个虚拟环境并默认把第三方包装到myenv/lib/python3.x/site-packages不会污染全局。而当虚拟环境被激活时PYTHONHOME这类变量也会被清空确保解释器不会错误地去加载系统目录里的库。2.3 为什么 venv 创建得这么快、占空间这么小正因为 venv 不是真正复制一份完整的 PythonLinux/macOS 下甚至不复制解释器本体所以创建速度极快通常在几秒内完成占用的磁盘空间也只有几 MB 到几十 MB。这也是它和后面要讲的 conda 最大的区别之一——conda 创建的独立环境会自带一套完整的 Python 运行时和二进制依赖体量往往大得多。明白了这个原理你就能理解很多坑的来源了因为 venv 依赖你创建它时指定的那个基础解释器所以如果你删掉了系统里的 Python或者把 venv 文件夹拷贝到一台 Python 版本不同的机器上环境就有很大概率废掉。这是后话第 5 章我会展开讲。3. 从创建到删除venv 生命周期全流程实操手册3.1 创建环境python -m venv 背后的细节首先确认你的 Python 版本够新。我建议使用 Python 3.7 以上因为新版 venv 的体验和稳定性都好不少。创建方式非常简单# 在项目根目录下执行 python -m venv venv这里第一个python是你当前全局环境里的解释器-m venv意思是调用标准库里的 venv 模块最后一个venv是环境文件夹的名字。很多人习惯把环境文件夹命名为.venv前面加个点隐藏目录因为 VSCode、PyCharm 等工具会默认识别这个名字git 也更方便忽略它。如果你本机装了多个 Python 版本想用某个特定版本创建环境可以写完整python3.11 -m venv venv311创建时还可以加参数最常用的是这两个--system-site-packages让虚拟环境允许访问全局装的第三方包。默认不开启因为我们的目的就是隔离但如果你全局已经有一堆常用的重型库比如 numpy又不介意共享开启可以省不少安装时间。--copies强制用复制而非符号链接的方式创建解释器Windows 默认就是复制Linux/macOS 下有特殊需求比如要把环境拷走才用到。3.2 激活环境三个平台的正确姿势激活命令在 Windows 和 Linux/macOS 下不一样我列个表格方便对照平台激活命令停用命令Windows CMDvenv\Scripts\activate.batdeactivateWindows PowerShellvenv\Scripts\Activate.ps1deactivatemacOS / Linux bashsource venv/bin/activatedeactivate激活成功后你会在终端提示符最前面看到(venv)这就是最直观的确认方式。如果没看到说明激活失败或者你根本还在外层。接下来可以进一步验证# Linux/macOS which python # 输出应该类似/path/to/your/project/venv/bin/python # Windows where python # 输出应该会包含你的 venv\Scripts\python.exe提示在 Windows 上如果你用 Git Bash激活文件路径是venv/Scripts/activate正斜杠也能用其他 shell 同理。关键是别敲错文件名。3.3 安装、导出与复现依赖环境激活后安装包用pip就行pip install requests pip install -r requirements.txt装完后你可以用pip list查看当前环境里所有安装的包。注意因为隔离你全局环境里以前装过的包在这个环境里都是不存在的需要重新安装。这是很多人刚接触虚拟环境时觉得麻烦的点但其实这正是它对你项目负责的表现。项目依赖整理推荐这么做# 导出当前环境的所有包及精确版本号 pip freeze requirements.txtrequirements.txt的格式很简单就是包名版本号比如requests2.32.3 flask3.0.0另外一台机器上只需要python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install -r requirements.txt三步走完环境完全复现再也不会出现我这个包是有的啊这种困扰。一个细节pip freeze会把当前环境里所有包都导出来如果有些包是某个库的传递依赖一般也会一起列出直接提交完全没问题。要是环境里装过 pip 之外的包管理工具残留建议先手动清扫一下再 freeze。3.4 退出与彻底删除一键清零的快乐不需要虚拟环境了直接执行deactivate回到全局环境。整个文件夹比如venv或.venv直接删除即可——这就是虚拟环境最爽的地方它是完全独立于系统的删了就是删了不会对全局 Python 产生任何残留影响。我也见过一些人用完后不删项目堆了一堆后积累了大量环境文件夹每个几百 MB。建议在项目生命周期结束后及时清理尤其做数据科学的朋友环境里动辄几个 GB 的重型库留着挺占磁盘的。4. 在真实开发环境里用好 venv编辑器集成与多版本 Python 并存4.1 VSCode 里选对解释器少走一半弯路VSCode 是目前最主流的 Python 编辑器之一。很多新手在 VSCode 里遇到明明激活了虚拟环境但运行时还是用全局 Python的问题根本原因往往是VSCode 里跑的 Python 插件和终端里的环境是两回事。在 VSCode 里你按CtrlShiftP打开命令面板输入Python: Select Interpreter选择你的venv里的 Python 解释器路径通常显示为./venv/bin/python或venv\Scripts\python.exe。选对之后插件会用这个解释器跑代码。但终端Terminal里的激活又是独立的——如果终端里没激活虚拟环境终端直接跑python还是全局的。解决方案有两种一是在终端里手动激活第 3.2 节的方法二是让 VSCode 自动激活。新版 VSCode Python 插件在你打开带.venv文件夹的项目时会自动检测并提示选择解释器选了之后新建的终端也会自动进入该环境。如果你的版本不支持可以设置python.terminal.activateEnvironment: true这个配置的意思是当终端启动时自动执行虚拟环境的激活脚本。我可以明确说配置好这一步之后你在 VSCode 里的开发体验会顺畅很多。4.2 PyCharm 的虚拟环境配置与注意事项PyCharm 对 venv 的支持更加一体化。新建项目时左侧的New environment using下拉框选VirtualenvPyCharm 会自动帮你创建venv目录并且在终端里自动激活。如果项目已经建好了打开File - Settings - Project: xxx - Python Interpreter点齿轮选Add选Existing environment然后指定 venv 里的 python 路径即可。这里我提一个容易忽略的点PyCharm 里跑脚本用的解释器是Project Interpreter里选的和 PyCharm 自带的 Terminal 里的环境可能不一致。所以如果你在 PyCharm 自带的终端里敲pip install要确保终端里的环境和你 Run 脚本的解释器是同一个。经验做法是建项目时让 PyCharm 生成 venv之后统一在终端里安装包并且在右下角状态栏确认解释器路径。4.3 多版本 Python 并存pyenv 是 venv 的最佳搭档很多人问我电脑上既有 Python 3.8 又有 Python 3.11怎么给不同项目匹配不同版本venv 本身只负责隔离包不负责管理解释器版本——但你可以先用版本管理工具选好解释器再用它创建 venv。最常用的是pyenvmacOS/Linux 下很流行。流程大概是pyenv install 3.11.7 pyenv local 3.11.7 # 在当前项目目录锁定 Python 版本 python -m venv venv # 此时创建的环境就是基于 3.11.7 的Windows 用户则常使用py这个官方启动器。安装多个 Python 版本后可以用py -3.11 -m venv venv311把解释器选择和依赖隔离两个问题分开处理各管好各的项目的可复现性就大幅提升。顺带说一句Python 3.3 之前流行的virtualenv和现在的标准库venv核心逻辑相似区别在于 virtualenv 速度更快、兼容更老的 Python、还支持环境搬迁等高级操作。如果不是被老项目绑定直接用python -m venv就够了它是官方现在推荐的正统姿势。5. 我在 venv 里踩过的坑排查链路与避坑清单5.1 现象一pip install 明明激活了还是装到全局这是出现频率最高的问题而且排查起来很有迷惑性。你执行了source venv/bin/activate提示符也出现了(venv)但运行pip install xxx之后在全局的site-packages里居然能看到它。正确的排查链路应该是先确认which pipWindows 是where pip看它是否指向 venv 目录。如果指向的是/usr/bin/pip或~/.local/bin/pip说明pip没有走虚拟环境。然后看echo $PATH检查 venv 目录是否排在前面。检查环境变量里有没有PIP_REQUIRE_VIRTUALENV有的配置会强制 pip 在虚拟环境外拒绝工作但也有版本会自动绕过。我遇到这类问题多数情况是用户同时装了 pipx、conda 或者有 shell 别名alias pip某个全局 pip导致 PATH 顺序被干扰。还有一种隐蔽情况在 Windows 下从 cmd 启动的终端激活了但你在 Git Bash 里跑 pip两条命令各自关联不同的环境检测逻辑。排查时先统一终端再一次性清掉 PATH 里的干扰项最可靠。5.2 现象二PowerShell 禁止运行激活脚本Windows 上首次运行venv\Scripts\Activate.ps1时经常报错无法加载文件 ...\Activate.ps1因为在此系统上禁止运行脚本这不是 venv 的问题而是 Windows PowerShell 默认执行策略是Restricted禁止运行任何 .ps1 脚本。解决办法有两种临时允许当前会话执行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process。永久改当前用户Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser。如果你不想动 PowerShell 策略直接改用 CMDvenv\Scripts\activate.bat或 Git Bashvenv/Scripts/activate就行这两种方式不涉及 .ps1 脚本同样能激活。5.3 现象三venv 里 import 不到系统里明明有的包很多人创建 venv 后惊奇地发现之前全局已经装好的 numpy、pandas在虚拟环境里突然 import 不到了——这是虚拟环境的本质不是 bug。默认情况下 venv 完全不读全局的site-packages每个环境从零开始装包。如果你确实希望新环境可以读取全局的第三方包创建时加上参数python -m venv --system-site-packages venv不过我的建议是如果项目需要 numpy 这类大型包直接在这个 venv 里装一份就好。因为全局包版本可能和你项目依赖冲突既然用了虚拟环境就别委屈求全干净才是它的价值。5.4 现象四整个 venv 文件夹换个机器就废了虚拟环境看似是一个文件夹打包就能带走实际上并不完全可移植。原因我在第 2.3 节说过了Linux/macOS 下 venv 里的python是指向创建它时那个解释器的符号链接而且pyvenv.cfg里的home字段记录的是本机 Python 的绝对路径。你把 venv 文件夹拷到另一台机器链接大概率指向不存在或版本不对的路径那个环境基本就废了。正确做法是项目目录只提交代码和requirements.txt在每台机器上重新创建 venv 并安装依赖。如果你实在想做一个可移植环境用virtualenv --relocatable或者直接改用 conda 环境甚至是 Docker 镜像都会有更好的效果——但那些就是另一个话题了。6. 从 venv 到更现代的依赖管理工具对比与选型建议6.1 venv、virtualenv、conda、poetry、uv谁在什么场合适用很多工具都提供虚拟环境能力但它们解决的问题各有侧重。我把常用方案整理成一个表工具本质优势痛点适合场景venvPython 标准库模块零依赖、轻量、官方维护仅管理 Python 包不管理解释器版本绝大多数普通项目团队协作最通用virtualenv第三方工具兼容老 Python、创建快、支持复制重定位需要额外安装逐渐被 venv 取代老版本 Python 项目conda跨语言的包环境管理能装二进制库如 C 扩展、CUDA、管理非 Python 包体积大、默认源慢数据科学、机器学习项目pipenvpip venv 封装同时管理依赖和虚拟环境生成 Pipfile性能一般依赖解析速度慢追求一键复现的应用开发poetry完整依赖管理打包现代 pyproject.toml 标准化、锁定精确版本学习曲线稍高发布 PyPI 包、复杂依赖的 Python 库uvRust 写的极速包管理创建环境和装包速度极快兼容 pip/PyPI相对年轻生态还在迭代新项目,想要极速体验这些工具并不是非此即彼的关系。我自己的经验是90% 的日常项目venv pip requirements.txt就够了它简单、通用、人人都懂。一旦项目里有复杂的分支环境、多语言依赖比如 Python 调 C 库或者想省掉手动管理 pip 的琐碎才升级到 conda 或 poetry。6.2 我的选型策略小项目、大项目、数据科学各怎么选给一个相对直接的建议脚本或轻量应用直接用python -m venv venv激活后 pip 安装导出requirements.txt。这一条适用于 90% 的场景步骤少出错概率也最低。团队协作、需要严格锁定版本用 poetry 或 uv。前者生态成熟pyproject.toml 能通过 lock 文件精确到每个传递依赖的版本后者如果你受够了 poetry 慢吞吞的解析值得尝试体验相当惊艳。机器学习/数据科学如果你跑的是 GPU 训练、需要 CUDA 环境、TensorFlow/PyTorch 一堆二进制依赖conda 真香因为它能把 CUDA、cudnn 这类非 Python 依赖也管起来。但项目足够标准时venv pip 也够用。不想折腾环境只想跑通代码直接用uv或pipenv让工具帮你自动创建和管理虚拟环境省去手动激活的步骤。说到底虚拟环境是解决问题的不是制造问题的。用最顺手的那套方案持续保持一个项目一个环境的习惯你会发现 Python 项目的可维护性提升一大截。最后分享一个这几年过来我最深刻的体会环境越干净排查问题的时间越少。曾经我花了一整晚找一个随机出现的报错最后发现是全局环境被另一个项目装了一个旧版本的库——从那天起我给每个项目建.venv就没再断过。升级系统 Python 前先看一眼你手里的项目环境是否还在正常转换新电脑或迁移环境时宁可重新pip install -r requirements.txt也别复制那个venv文件夹。这些都成了我刻进本能的操作习惯也希望你从这篇指南开始养成属于你自己的那套流程。