python虚拟环境和主环境有什么区别，装包前我踩过的坑

上周三下午，我在那台跑了三年的 Ubuntu 小机器上给爬虫项目装 pdfplumber，pip 一敲下去就提示权限不足。python虚拟环境和主环境有什么区别，这个问题我当时真没往深里想，顺手加了 sudo，结果装完系统自带的 python 直接报错起不来，代价是重装了一遍，连另一个项目的依赖也一起搅乱了。

那台机器我是怎么被坑的

我一开始以为 python虚拟环境和主环境有什么区别 只是个概念题，真出事才知道它决定你的包装到哪儿。装完发现 requests 被降级成老版本，另一个用 flask 的项目启动直接报 ImportError。

老实说，那会儿我还在用 requirements.txt 一把梭，谁后装谁覆盖。你别笑，很多人的服务器就是这么一点点被搞脏的。

我当时先看报错栈，再看装到了哪个目录，一眼就看出两个项目的包挤在同一个 site-packages 里。

后来我索性把两个项目分开目录放，各管各的，问题才彻底消停。

我后来才明白，python虚拟环境和主环境有什么区别，看的从来不是 venv 这个命令本身，而是 python 和 pip 有没有配成一对。系统里同时躺着两个解释器的时候，pip 装进 A，python 跑的却是 B，这种错位最难查。

虚拟环境的作用：把依赖关进自己的目录

虚拟环境的作用说起来就一句话：给每个项目单独一份 site-packages 和一个 python 入口，装包只影响这个目录。

主环境的包装在 /usr/lib/python3/dist-packages 这类位置，全局可见，所有项目共用。venv 的包落在 .venv/lib/python3.x/site-packages，删掉整个目录等于把环境清干净，比一个个 pip uninstall 省事。

顺手提一句，python -m venv 比直接敲 venv 稳，前者能保证用的是你想要的那个解释器版本。这个习惯我吃了一次亏之后才改过来。

这也是我现在回答 python虚拟环境和主环境有什么区别 的第一层：主环境是公用的，虚拟环境是私有的。

有个细节我吃过亏：venv 并不复制标准库，它只是指向系统 python 的二进制。系统 python 一升级或者被删，你的虚拟环境跟着废掉，别问我怎么知道的。

第一步：建一个干净的隔离目录

进项目根目录跑这一条。我习惯把环境目录命名成 .venv，前面加个点，编辑器默认不索引它。

Debian 和 Ubuntu 上得先补一句，python3-venv 不是默认装的，缺了会报 ensurepip is not available，我第一次就在这儿卡了十分钟。macOS 和 Windows 的官方安装包已经带好，跳过这步。

sudo apt install python3-venv
python3 -m venv .venv
source .venv/bin/activate
which python
python -c "import sys; print(sys.prefix)"

Windows 的 cmd 里第二步换成 .venv\Scripts\activate.bat，PowerShell 里是 .venv\Scripts\Activate.ps1。还有个细节：which 在 cmd 和 PowerShell 里不存在，要换成 where python，PowerShell 也可以用 Get-Command python。不同 shell 写法不一样，以官方文档为准。

venv 建环境的时候会把 pip 一起装进去，不用你再单独装一遍。想复用主环境已经装好的包就加 --system-site-packages，我一般不这么干，隔离就白做了。

激活之后 which python 输出的路径会变成项目里的 .venv/bin/python，重点看这一行有没有指到项目目录。要是还指着 /usr/bin/python，说明激活没生效，检查一下当前 shell。

sys.prefix 打印的是环境根目录，路径对得上就说明进去了。很多人问 python虚拟环境和主环境有什么区别，问的其实就是这一步该看哪儿。

第二步：看装载路径到底变了没

光看 which 还不够，我一般再确认一次 sys.path。下面这条会把搜索路径一行一行打出来。

python -c "import sys; [print(p) for p in sys.path]"

输出大概长这样：开头是空串，代表当前目录；中间几行是 .venv 下的 site-packages；最后才是系统目录。你重点看 .venv 那几行排在哪，排在系统目录前面，包才会优先从这儿加载。

我在编辑器里还踩过一次：右下角解释器没切到 .venv，终端里明明激活了，跑起来照样走主环境。后来我养成习惯，动手前先看一眼 sys.executable。

这就是 python虚拟环境和主环境有什么区别 的第二层：谁在 sys.path 前面，谁说了算。

退出用 deactivate，回到主环境。我踩过的坑是开着两个终端，一个激活了一个没激活，pip install 装错地方，白跑半小时。

venv和conda的区别：一个管包，一个管解释器

venv和conda的区别，我觉得最直观的是 conda 能给你装一个新的 python 版本，venv 只能拿你手上那个解释器去建环境——想换版本，得先自己把另一个 python 装好，再用它跑 -m venv，不然建出来还是系统那个。

conda 是独立的分发体系，自带包仓库和二进制包。numpy、pytorch 这类科学计算的东西装起来省事，需要 CUDA 的时候尤其明显。

conda create -n demo python=3.12
conda activate demo
conda env list

conda env list 会列出所有环境，带星号的是当前激活的那个。环境目录默认在 conda 的 envs 下面，不在你项目里，这点跟 venv 正好相反。

很多人把 python虚拟环境和主环境有什么区别 当成 venv 的用法问题，其实它是个路径问题。conda 环境里 pip list 和 conda list 的结果经常对不上，别拿一个去核另一个。

代价是重。一个 conda 环境动辄几个 G，纯 web 项目或者写个小脚本，我真觉得没必要。我现在 venv 为主，conda 只在跑模型的时候开。

venv 和 conda 也别混用。在 conda 环境里再套一层 venv，pip 到底指向谁全看 PATH 顺序，这种坑很难查。老实说，venv和conda的区别 比 python虚拟环境和主环境有什么区别 更容易让人吵起来。

补一句，conda 里装包优先用 conda install，找不到再退到 pip。两边混着来，依赖树很容易搞成一团。

我现在的固定做法

每个项目一个 .venv，写进 .gitignore，依赖用 pip freeze 落到 requirements.txt。要重建环境，删目录重跑一次 venv 就行，比修快得多。

requirements.txt 我一般只在交付的时候才生成，平时 pip freeze 看一眼就够，免得装个临时调试工具还得重新生成一遍。环境这东西，建的时候多花两分钟，后面能少折腾两小时。

你要是还在 sudo pip install，赶紧停手。python虚拟环境和主环境有什么区别，说到底就是弄清楚你的包落在哪个目录，剩下的都是顺手的事。这条路我走错过一次，代价是一台机器的干净环境，你别重复。