Virtualenv能隔离包依赖，因为它为每个环境创建独立Python解释器副本，并将site-packages指向专属子目录，系统级包完全不可见；未激活环境或误装到全局会导致ImportError。

Virtualenv 为什么能隔离包依赖

因为每个 virtualenv 创建的是独立的 Python 解释器副本，它把 site-packages 目录指向自己专属的子目录，系统级或用户级安装的包完全不可见。不是靠“假装没装”，而是真的没路径、没入口。

常见错误现象：ImportError: No module named 'requests' 却在系统里明明 pip list 看到了——八成是进了错的环境，没激活，或者用 pip install 装到了全局。

• 必须用 source venv/bin/activate（Linux/macOS）或 venv\Scripts\activate.bat（Windows）激活后才能生效
• which python 或 where python 能立刻验证当前解释器是否指向虚拟环境内
• 一旦终端关闭，环境自动退出；别指望“后台常驻”——它本就不该那样用

创建和命名虚拟环境的实用习惯

别直接在项目根目录下叫 venv——虽然常见，但容易被误提交、误清理，也掩盖了环境用途。推荐按用途或 Python 版本区分：

• 用 python -m venv .venv-py39 显式绑定 Python 小版本，避免换机器后行为不一致
• 项目里放 .venv- 开头的目录，再加 .gitignore 一行 .venv-*/，安全又清晰
• 不推荐用 virtualenv 包（第三方）代替内置 venv 模块，除非你真需要旧 Python 3.2–3.6 支持

pip install 时漏掉 --upgrade pip 的后果

新虚拟环境里的 pip 默认是安装时的旧版本（比如 21.x），而现代包（如 torch、pydantic）可能依赖较新的依赖解析逻辑。不升级就直接 pip install，容易触发 ERROR: Could not find a version that satisfies the requirement，尤其在多层依赖场景下。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

正确顺序只有一条铁律：

• 激活环境后第一件事：运行 python -m pip install --upgrade pip
• 之后再装项目依赖：pip install -r requirements.txt
• 如果 requirements.txt 里写了 pip==22.3.1 这类硬版本，反而要小心——它可能锁死你无法升级，除非你明确需要兼容性

什么时候不该用 Virtualenv

不是所有隔离需求都适合 venv。比如你要跑一个带 GUI 的 PyQt5 应用，又想打包成单文件，用 venv 反而增加分发复杂度；再比如 CI 流水线中频繁创建销毁环境，venv 启动慢、缓存差，这时候 pipx 或容器更合适。

真正该警惕的是：把 venv 当成“解决所有依赖问题”的银弹。它不处理 C 扩展编译差异、不跨平台兼容、也不保证 setup.py 行为一致——这些得靠 pyproject.toml + build 工具链补位。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！