最可靠判断是否在虚拟环境的方法是比较 sys.prefix 与 sys.base_prefix：若二者不等，则处于激活的虚拟环境（含 conda）；若相等，则为系统 Python 或未激活环境；PyInstaller 等场景需用 getattr 防 base_prefix 缺失。
用 sys.prefix 判断是否在虚拟环境中最直接但有陷阱
是的，sys.prefix 是最常用的方法——它指向当前 Python 解释器的“安装根目录”。在系统 Python 中，这个路径通常是 /usr、/usr/local 或 C:\Python39 这类全局位置；而在虚拟环境中，它会指向虚拟环境目录本身（比如 /path/to/venv）。但关键在于：不能只看路径名是否含 venv 或 env，因为用户可能手动命名虚拟环境为 myproject，也可能把系统 Python 装在 /opt/python 这种“像虚拟环境”的路径下。
真正可靠的判断逻辑是：比较 sys.prefix 和 sys.base_prefix。后者始终指向原始 Python 安装位置。只有当两者不相等时，才说明当前运行在虚拟环境中（包括 venv、venv 创建的环境，以及 conda 环境——conda 3.7+ 也设置了 base_prefix）。
-
sys.base_prefix == sys.prefix→ 系统 Python 或未激活的虚拟环境 -
sys.base_prefix != sys.prefix→ 当前已激活虚拟环境（含 conda） - 注意：在 PyInstaller 打包后的可执行文件中，
base_prefix可能不存在，需加getattr(sys, 'base_prefix', None)防错
为什么不用 sys.real_prefix？
sys.real_prefix 是旧版 virtualenv（venv 模块和新版 virtualenv 已弃用它。如果你在代码里检查 hasattr(sys, 'real_prefix')，在 Python 3.12 + venv 下永远返回 False，导致误判。现在所有标准虚拟环境都统一走 base_prefix 路径。
- virtualenv 20.0+ 和
python -m venv都不设real_prefix - conda 环境从 4.6 开始也不依赖
real_prefix，而是模拟base_prefix - 硬检查
real_prefix的代码在新环境中会漏掉所有 venv 场景
一行安全判断函数怎么写？
下面这个函数兼顾兼容性与简洁性，覆盖 Python 3.3+ 的所有常见环境：
立即学习“Python免费学习笔记（深入）”；
import sys
def in_venv():
return getattr(sys, 'base_prefix', sys.prefix) != sys.prefix
它利用了默认值机制：如果 base_prefix 不存在（如某些嵌入式 Python 或极老环境），就退回到用 sys.prefix 自比——此时必然相等，结果为 False，符合“非虚拟环境”的预期。不需要额外 try/except，也没有路径字符串解析。
- 不要用
os.environ.get('VIRTUAL_ENV')：它依赖 shell 激活，脚本被python script.py直接调用时可能为空 - 不要解析
sys.executable：Windows 上 conda 可能用硬链接，路径未必含 env 名 - 这个函数可在任何导入时机调用，无需 import 其他模块
实际使用中容易忽略的边界情况
即使逻辑正确，部署时仍可能踩坑：
- 在 Docker 容器中，如果 base image 是
python:slim并手动pip install包，没建 venv，in_venv()返回False——这是对的，但有人误以为“容器=虚拟环境” - PyOxidizer 或 py2exe 打包后，
base_prefix可能被重定向到资源目录，此时in_venv()可能意外返回True，需结合打包工具文档确认行为 - 在 GitHub Actions 的
actions/setup-python中，默认不激活 venv，但pip安装到用户 site-packages，此时in_venv()仍是False，别把它当成“隔离环境”的代理指标
判断是否在虚拟环境中，只是起点；后续逻辑（比如要不要自动 pip install）还得结合 site-packages 位置、pip list --local 输出或明确的配置开关来决定。
