Python通过比较sys.prefix与sys.base_prefix是否相等来识别虚拟环境：相等为系统环境，不等则为虚拟环境；site模块据此动态插入虚拟环境的site-packages路径到sys.path。
Python 解释器如何识别当前虚拟环境
Python 启动时通过 sys.base_prefix 和 sys.prefix 判断是否处于虚拟环境中。在系统 Python 中两者相等；在虚拟环境中，sys.prefix 指向虚拟环境根目录（如 /path/to/venv），而 sys.base_prefix 仍指向原解释器位置（如 /usr/bin/python3.11）。Python 内部多个路径查找逻辑（如 site-packages 加载、脚本搜索）都依赖这个差异做分支处理。
验证方式很简单：
import sys
print("prefix:", sys.prefix)
print("base_prefix:", sys.base_prefix)
print("in venv:", sys.prefix != sys.base_prefix)
注意：某些打包工具（如 PyInstaller）或容器化运行时可能篡改这两个值，导致误判。
site-packages 目录是如何被动态插入到 sys.path 的
虚拟环境激活后，Python 并不会“修改”全局 sys.path，而是在启动阶段由 site 模块自动注入虚拟环境专属的 site-packages 路径。关键机制在于：site.py 会检查 sys.prefix 是否与 sys.base_prefix 不同，若不同，则将 os.path.join(sys.prefix, "lib", f"python{sys.version_info.major}.{sys.version_info.minor}", "site-packages") 插入 sys.path[0] 之前的位置。
立即学习“Python免费学习笔记（深入）”；
- 这个插入发生在
import site阶段，早于用户代码执行 - 第三方包安装（如
pip install requests）默认写入该site-packages，因此对其他环境不可见 - 若手动修改
sys.path或设置PYTHONPATH，可能绕过隔离，导致意外导入
activate 脚本到底改了什么环境变量
source venv/bin/activate（bash/zsh）或 venv\Scripts\activate.bat（Windows）本质是 shell 层面的路径劫持，不涉及 Python 解释器内部状态变更。它主要修改：
-
PATH：把虚拟环境的bin/（或Scripts/）前置，确保python、pip命令调用的是虚拟环境内的可执行文件 -
_OLD_VIRTUAL_PATH：保存原始PATH，供deactivate恢复 -
PS1（仅 bash/zsh）：修改命令行提示符，视觉提示当前环境
重要提醒：activate 不改变已运行 Python 进程的行为。如果你在激活前已启动了 Python REPL 或 Jupyter 内核，它仍然使用原来的 sys.prefix 和 sys.path —— 必须重启解释器进程才能生效。
为什么 conda 环境和 venv 表现不同但底层思路一致
conda 不依赖 sys.base_prefix 判定，而是通过硬链接/复制 Python 可执行文件 + 独立的 pkgs/ 缓存 + 运行时重写 sys.executable 和 sys.prefix 实现隔离。它的 conda activate 同样修改 PATH，并注入大量 conda 特有环境变量（如 CONDA_DEFAULT_ENV、CONDA_PREFIX）。
关键共性在于：两者都让 python 命令指向一个“包装过”的解释器入口，该入口在初始化阶段主动设定自己的 sys.prefix 和加载路径。差异只在实现粒度：venv 复用宿主解释器二进制，靠 Python 自身逻辑隔离；conda 提供完整独立的 Python 副本，控制力更强但也更重。
容易忽略的一点：无论 venv 还是 conda，只要直接调用绝对路径的 Python（如 /usr/bin/python3.11 script.py），就完全绕过所有虚拟环境逻辑 —— 隔离只作用于“通过 PATH 查找的 python 命令”。
