python虚拟环境通过独立site-packages目录、重定向path使python/pip指向本地脚本、初始化时将虚拟环境路径插入sys.path前端并默认排除全局site-packages，实现依赖硬隔离。
因为虚拟环境和全局环境是完全隔离的两个 Python 运行空间，pip install 写入的是当前激活环境的 site-packages 目录，而全局 Python 解释器根本不会去那里查找模块。
virtualenv / venv 的隔离机制是怎么工作的？
虚拟环境不是“改了某个配置让 pip 换地方装”，而是通过复制一份独立的 Python 解释器 + 重置 sys.path 实现硬隔离：
- 激活后，
python和pip命令实际指向.venv/bin/python（macOS/Linux）或.venv\Scripts\python.exe（Windows），不是系统 Python -
sys.path开头强制插入虚拟环境自己的lib/python3.x/site-packages，全局 site-packages 被默认排除（除非创建时显式启用--system-site-packages） - 未激活时运行
pip install，调用的是系统 pip，安装路径在/usr/lib/python3.x/site-packages或%LOCALAPPDATA%\Programs\Python\...
为什么 PyCharm 终端里 pip 还是装到全局？
PyCharm 终端默认不自动激活项目关联的虚拟环境，尤其在以下情况会失效：
- 终端启动时项目解释器已设置，但没勾选 “Activate virtualenv in terminal”（Settings → Tools → Terminal）
- 手动执行过
deactivate或新开终端窗口，导致激活状态丢失 - 虚拟环境路径含中文或空格，某些 shell 无法正确 source
activate脚本 - PyCharm 使用了 Conda 环境但终端未加载 conda 初始化脚本（如 Windows 上没运行
conda init powershell）
验证方法：在终端中运行 which python（macOS/Linux）或 where python（Windows），输出路径必须包含 .venv 或你设的环境名；再运行 pip show pip，看 Location: 是否落在同一目录下。
conda 环境和 venv 环境混用时 import 失败
conda 和 venv 底层机制不同，不能互相激活或共享包：
- 用
conda activate myenv激活的环境，pip install安装的包仍属于该 conda 环境，但可能破坏 conda 的依赖图（尤其当 conda 不认识该包时） - 在 conda 环境里运行
python -m venv new_venv，生成的是嵌套虚拟环境，new_venv与原 conda 环境无关 - IDE（如 VS Code）若只配置了解释器路径却没同步激活 conda 环境，会导致 Python 进程读不到 conda 安装的包
最稳妥的做法：一个项目只用一种环境工具。数据科学类项目优先用 conda，通用开发推荐 python -m venv + requirements.txt。
容易被忽略的关键点
环境是否生效，**唯一可信信号是命令行提示符前缀**（如 (.venv) 或 (myenv)），而不是“我刚刚点了 PyCharm 设置里的解释器”。每次打开新终端、切换项目、重启 IDE 后，都得重新确认激活状态；pip list 显示的包列表，永远只反映当前 shell 进程所用解释器的真实现场。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
