Python 虚拟环境建好了，为什么 pip 还是装到了系统里？

刚学 Python 的时候，很多人都走过同一条弯路：照着教程 python -m venv .venv 建了虚拟环境，满心以为从此互不干扰，结果一 pip install，包还是装到了系统 Python 里，换台机器或者换个项目就冲突。问题往往不在 venv 本身，而在「你以为激活了，其实没有」。

先确认：你现在到底在哪个环境里

排障永远先问一句：当前用的 python 和 pip 是谁？

which python
which pip
python -c "import sys; print(sys.executable)"

如果这三处指向的还是 /usr/bin/python3 或者系统路径，而不是项目目录下的 .venv/bin/python，那后面的安装注定装错地方。虚拟环境的激活脚本只是改了当前 shell 的 PATH，让 .venv/bin 排在前面；新开一个终端、换了一个 shell 会话、或者只在编辑器里点了运行，激活状态都不会跟着过去。

最容易踩的三个坑

第一，建完忘了激活。python -m venv .venv 只负责建目录，不负责激活。Linux/macOS 要执行 source .venv/bin/activate，Windows 是 .venv\Scripts\activate。激活成功后，命令行提示符前面会多一个 (.venv)，没有这个前缀就别急着装包。

第二，在错误的 shell 里激活。VS Code 的集成终端、PyCharm 的终端、系统终端可能是不同的 shell 配置，激活只对当前会话有效。正确做法是：激活之后立刻在同一个终端里跑 which python 验证，确认路径是 .venv/bin/python 再装包。

第三，用错了 pip。即使激活了，pip 也可能因为 PATH 里残留的别名或旧的 pip 可执行文件而指向别处。最稳的写法是永远用模块方式调用：

python -m pip install requests

python -m pip 保证 pip 和当前 python 是同一套解释器，基本可以杜绝「装到了别处」的问题。把这条当成默认习惯，比每次排查省事得多。

一个干净的日常流程

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt

项目里再配一个 .gitignore，把 .venv/ 排除在版本控制之外。虚拟环境本身不需要提交，别人拿到代码后用 requirements.txt 重建一个即可。需要记录依赖时，用 python -m pip freeze > requirements.txt，但注意它会把所有已装的包都列出来，长期维护的项目最好手工精简成直接依赖。

什么时候不用虚拟环境

只写一次性小脚本、用系统自带的工具链、或者在容器里已经隔离好的环境中，虚拟环境反而是多余的步骤。但只要一个项目开始有第三方依赖、或者同一台机器上有两个项目依赖版本不同，虚拟环境就是最低成本的隔离手段。容器、conda 都是更重的隔离方案，venv 轻到几乎没有理由不用。

小结

• 建环境不等于激活环境：看提示符有没有 (.venv)，再看 which python。
• 装包优先用 python -m pip，别裸用 pip。
• 新终端、新 shell 都要重新激活，激活状态不跨会话。

把这三点养成习惯，「包又装错地方了」这件事，基本就不会再发生了。