venv是最轻量、最直接的Python虚拟环境方案，Python 3.3+自带，无需额外安装，通过python -m venv创建完全隔离环境，确保依赖互不干扰且宿主机不受污染。
venv 是最轻量、最直接的方案，不需要额外安装工具，且能完全隔离宿主机 Python 环境。只要不手动修改系统级路径或全局 pip，宿主机就几乎不可能被污染。
用 python -m venv 创建干净隔离环境
这是 Python 3.3+ 自带的标准方式，不依赖第三方工具，也避免了 virtualenv 额外安装带来的潜在干扰。
- 在虚拟机里任意目录执行：
python -m venv myenv，生成的myenv目录只包含解释器副本和空的site-packages - 激活后所有
pip install安装的包都只写入myenv/lib/python*/site-packages/，宿主机的/usr/lib/python*/site-packages/或C:\Python*\Lib\site-packages\完全不受影响 - 如果虚拟机里装了多个 Python 版本（比如
python3.9和python3.12），可以用python3.9 -m venv py39_env显式指定解释器，避免误用默认版本
激活后务必确认当前 python 和 pip 指向虚拟环境
很多人跳过这步验证，结果在宿主机上装了一堆包却以为在环境里 —— 这是污染宿主机最常见的原因。
- 运行
which python（Linux/macOS）或where python（Windows），输出应为myenv/bin/python或myenv\Scripts\python.exe，而不是系统路径 - 运行
pip debug --verbose，检查install_path是否落在myenv/目录内 - 如果提示符没显示
(myenv)，说明没激活成功；Windows 下常见错误是双击activate.bat而不是在命令行中运行它
别碰 --system-site-packages，除非你明确需要全局包
这个参数会让虚拟环境“看到”宿主机已安装的包，看似省事，实则破坏隔离性。
- 一旦启用，
pip list会混显宿主机和虚拟环境的包，pip freeze输出不可靠，导出的requirements.txt可能漏掉关键依赖 - 某些包（如
setuptools、wheel）在宿主机升级后可能意外影响虚拟环境行为，尤其在 CI/CD 或复现环境时出问题 - 真有需要共享的包（比如
numpy这类大体积、极少变更的库），建议用pip install --target手动复制到虚拟环境，而不是开启继承
退出和删除要彻底，别留尾巴
实验结束不清理，下次启动容易误用旧环境，甚至因残留缓存导致 pip 行为异常。
立即学习“Python免费学习笔记（深入）”；
- 退出用
deactivate，不是关终端窗口 —— 关窗不会重置PYTHONPATH或PATH，下一次打开终端仍可能沿用旧路径 - 删除环境直接删整个文件夹：
rm -rf myenv（Linux/macOS）或rmdir /s myenv（Windows），不要只清空site-packages - 特别注意：PyCharm 或 VS Code 如果曾将该环境设为项目解释器，关闭项目后也要手动清除解释器缓存，否则重启 IDE 可能自动重连旧路径
python 和 pip 始终指向 venv 目录”。任何绕过 venv 直接调用系统 pip 的操作，哪怕只执行一次，都可能埋下隐患。 
