venv 通过符号/硬链接复用系统 Python 二进制和标准库，仅新建 pyvenv.cfg、bin/（或 Scripts\）和 lib/pythonX.X/site-packages/，启动时依据 pyvenv.cfg 的 home 路径加载内置模块，并以自身路径为 sys.prefix 确保包隔离。
venv 是怎么隔离 Python 解释器的
它不复制整个 Python 安装，而是用符号链接（Linux/macOS）或硬链接（Windows）复用系统 Python 的二进制文件和标准库，只新建 pyvenv.cfg、bin/（或 Scripts\）和 lib/pythonX.X/site-packages/ 三个关键部分。解释器启动时读取 pyvenv.cfg 中的 home = ... 路径，就知道该从哪加载内置模块；同时把自身所在目录设为 sys.prefix，让 site-packages 自动指向虚拟环境内的包目录。
为什么 pip install 后包只在 venv 里生效
因为 pip 被安装在虚拟环境的 bin/pip（或 Scripts\pip.exe），它内部硬编码了对应的 sys.executable 和 sys.prefix。执行时会把包解压/编译到 lib/pythonX.X/site-packages/，而这个路径不在系统 Python 的 sys.path 里。你手动激活后，PATH 优先找到的是虚拟环境里的 pip 和 python，没激活时调用的仍是系统版本。
- 不激活也能用：
/path/to/venv/bin/python -m pip install requests - 激活只是改
PATH和PYTHONHOME环境变量，不是魔法 -
pip list显示的包来源，取决于当前python解释器的site-packages路径
venv 和 conda、poetry 的根本区别在哪
venv 只管 Python 解释器和纯 Python 包的隔离，不碰编译器、C 库、非 Python 工具（如 gcc、node）。conda 是完整环境管理系统，能装不同版本的 Python、NumPy、CUDA 驱动甚至 R；poetry 侧重依赖解析与锁定，底层仍用 venv 或 virtualenv 做隔离。如果你项目依赖 numpy + ffmpeg + rustc，venv 本身解决不了后两者——它连 ffmpeg 装在哪都不知道。
常见误操作：直接拷贝 venv 目录会出问题
因为 pyvenv.cfg 里记录了原始 home 路径，且部分可执行文件（尤其是 Windows 上的 python.exe）可能硬编码了解释器位置。拷贝后运行会报错：Could not find platform independent libraries 或直接闪退。正确做法是：在目标机器上重新运行 python -m venv new_venv，再用 pip install -r requirements.txt 重装。
立即学习“Python免费学习笔记（深入）”；
- 跨平台拷贝必炸（比如 macOS 打包的 venv 放到 Linux 运行）
-
venv不包含 Python 解释器本体，只存路径引用 - 想“打包”环境，应该导出依赖：
pip freeze > requirements.txt，而不是打包整个目录
