为什么自学Python建议创建虚拟环境？venv使用教程

南乔

发布时间：2026-11-10| 8人浏览过

原创

深入解析自学Python为什么必须尽早使用虚拟环境，详细讲解Python官方内置venv模块的创建、激活、包管理、依赖导出及跨平台排错完整教程。

自学 Python 时，建议从一开始就为每个练习或独立项目建立专属的虚拟环境。虚拟环境是一个独立的目录沙盒，内部拥有独立的 Python 解释器副本和第三方包安装路径。使用它可以彻底隔离项目依赖、避免全局库版本相互践踏、保护系统环境不被污染，并在项目废弃时实现零残留清理。Python 官方自 3.3 版本起内置了 venv 模块，无需安装额外工具即可直接使用。

为什么自学Python建议创建虚拟环境？

许多初学者在刚开始学习 Python 时，习惯直接打开终端或命令行，执行 pip install xxx 将所有学习过程中用到的第三方库统统安装到全局环境中。在只写一两个单文件脚本的最初几天，这种做法似乎很方便，但随着练习题目增多、涉及的技术方向变广，这种“全局一把梭”的安装模式很快就会引发一系列令人抓狂的技术故障。

1. 避免第三方库的版本冲突（“依赖地狱”）

不同开源库对其底层依赖包有明确的版本要求。例如，你在学习网络爬虫时，某个爬虫框架指定需要 urllib3 < 2.0.0；而当你随后学习自动化测试或某个新发布的 API 客户端时，它却强制依赖 urllib3 >= 2.1.0。如果你在全局环境中直接安装后者，pip 会自动将旧版本的 urllib3 覆盖卸载。结果就是：刚写完的爬虫脚本突然报错崩溃，而你可能根本不知道是哪个包在什么时候破坏了原有环境。

2. 防止污染和破坏操作系统基础环境

在 macOS 和多数 Linux 发行版（如 Ubuntu、Fedora）中，操作系统自带的某些系统管理工具本身就是用 Python 编写的。如果你通过管理员权限在全局运行 pip install，很有可能意外覆盖系统关键库，导致系统级应用报错甚至软件包管理器损坏。从较新的 Python 和操作系统版本开始（如 Debian 12 / Ubuntu 23.04 及以上），系统默认会通过 PEP 668 限制用户向全局环境写入包，直接抛出 externally-managed-environment 错误，强制要求在虚拟环境中安装。

3. 精确导出与团队/跨机器复现依赖

自学过程中，你迟早需要将写好的代码上传到 GitHub、发给同学交流，或者部署到云服务器运行。如果在全局环境中执行 pip freeze > requirements.txt，输出的清单会混杂你近几个月安装过的几十甚至上百个无关包。别人拿到清单后无法正常安装，你也无法分清这个练习到底依赖哪些库。而在独立的虚拟环境中，pip freeze 只会输出当前项目真正引用的包，清单干净、准确。

4. 零成本试错与推倒重来

自学阶段不可避免会装错包、配置失败或尝试各种实验性库。在全局环境中，逐个卸载包不仅费时费力，还经常残留无用的间接依赖。使用虚拟环境时，如果你把环境搞乱了，只需直接删除该环境文件夹，重新执行一条创建命令，几秒钟就能获得一个崭新的、完全干净的环境。

venv 模块的工作原理简析

自 Python 3.3 起，Python 官方标准库内置了 venv 模块。很多初学者误以为“虚拟环境”是一套庞大的虚拟机或模拟器，其实它的实现机制非常轻量与巧妙：

轻量级目录结构：创建虚拟环境时，venv 只是在你的工程目录下建立一个文件夹（通常命名为 .venv），并在其中创建 bin（macOS/Linux）或 Scripts（Windows）、lib/site-packages 等几个子目录。
文件符号链接（或轻量包装可执行文件）：它不会完整复制整套庞大的 Python 核心动态库，而是通过符号链接（Symlink）或几百 KB 的启动引导程序，将解释器指向宿主机的 Python。
环境重定向配置：目录中的核心文件是 pyvenv.cfg，里面记录了宿主机 Python 的基准路径（home）。当启动该目录下的解释器时，Python 会自动将第三方模块搜索路径（sys.path）限定在该虚拟环境的 site-packages 下。
终端环境变量注入：“激活”虚拟环境，本质上只是运行一段 Shell 脚本，把虚拟环境的 bin 或 Scripts 路径临时追加到当前终端会话的 PATH 环境变量最前端，使得后续输入的 python 和 pip 优先匹配虚拟环境内的命令。

venv 完整使用教程

下面按照实际项目开发的规范流程，详细介绍如何创建、激活、使用以及维护一个 Python 虚拟环境。

第一步：确认 Python 版本并新建项目目录

首先打开系统终端（Windows 下可使用 PowerShell 或 CMD，macOS/Linux 下使用 Terminal），确认 Python 解释器版本在 3.3 以上：

python --version
# 在部分 macOS/Linux 系统上，如果 python 指向旧版本，请使用 python3：
python3 --version

# 示例终端输出：
Python 3.11.8

接着，在任意合适的工作路径下为你的学习项目创建一个专属目录，并进入该目录：

mkdir demo_project
cd demo_project

第二步：创建虚拟环境

在项目根目录下，使用 -m venv 命令创建虚拟环境。通常社区规范推荐将虚拟环境目录命名为 .venv（以点开头在 Linux/macOS 下为隐藏文件夹）或 venv：

# Windows 环境执行：
python -m venv .venv

# macOS / Linux 环境执行：
python3 -m venv .venv

命令执行完毕后，终端不会有明显的文本输出。此时查看当前目录，会发现新增了一个名为 .venv 的文件夹。其内部目录结构如下：

.venv/
├── pyvenv.cfg            # 记录基础 Python 解释器路径的核心配置文件
├── bin/ (Windows 为 Scripts/)
│   ├── activate          # 各种 Shell 的激活脚本
│   ├── python (或 python.exe)
│   └── pip (或 pip.exe)
└── lib/
    └── python3.x/site-packages/  # 未来所有通过 pip 安装的第三方包均存放在此

第三步：激活虚拟环境（核心步骤）

创建目录后，环境并不会自动生效，必须先执行激活脚本。不同操作系统和终端环境的激活命令有所不同：

操作系统 / 终端类型	激活命令	退出命令
macOS / Linux (bash / zsh)	`source .venv/bin/activate`	`deactivate`
Windows (PowerShell)	`.venv\Scripts\Activate.ps1`	`deactivate`
Windows (CMD / 命令提示符)	`.venv\Scripts\activate.bat`	`deactivate`
Git Bash (Windows)	`source .venv/Scripts/activate`	`deactivate`

如何判断是否激活成功？
激活成功后，终端命令行提示符的最左侧会出现被括号包裹的虚拟环境名称，例如：(.venv) user@machine:~/demo_project$ 。
你也可以通过查询命令路径进行双重确认：

macOS/Linux 下执行：which python，输出应为 .../demo_project/.venv/bin/python
Windows 下执行：where python，第一行输出应为 ...\demo_project\.venv\Scripts\python.exe

Windows PowerShell 常见报错：无法加载文件，因为在此系统上禁止运行脚本
这是 Windows 针对 PowerShell 默认启用的安全执行策略限制。只需以管理员身份打开 PowerShell，执行以下命令修改执行策略即可：
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
选择 [Y] 是，随后重新打开普通终端即可正常激活。

第四步：在虚拟环境中安装与管理依赖包

确认激活了 (.venv) 之后，所有的 pip 操作都将安全地限定在 .venv 内部，绝不会影响外部系统：

# 升级虚拟环境内的 pip 工具
python -m pip install --upgrade pip

# 安装需要的第三方库（以 requests 为例）
pip install requests

你可以随时查看已安装包的存放路径，验证它确实落在了虚拟环境中：

pip show requests

# 示例输出片段：
Name: requests
Version: 2.31.0
Location: /Users/yourname/demo_project/.venv/lib/python3.11/site-packages
Requires: certifi, charset-normalizer, idna, urllib3

第五步：导出与还原依赖清单（requirements.txt）

当项目功能开发完成，或者需要将代码分享给他人、部署到远程服务器时，需要通过依赖清单记录所有安装的第三方包：

# 导出当前虚拟环境中的所有依赖及其精确版本号
pip freeze > requirements.txt

导出的 requirements.txt 文件内容清晰、简洁：

certifi==2024.2.2
charset-normalizer==3.3.2
idna==3.6
requests==2.31.0
urllib3==2.2.1

当另一台电脑或同事获取到你的项目代码后，只需同样新建并激活一个空白虚拟环境，然后执行一条还原命令即可一键安装完全一致的依赖：

pip install -r requirements.txt

第六步：退出与彻底删除虚拟环境

当你暂时完成该项目的开发，或者需要切换到其他全局终端任务时，执行以下命令即可退出当前虚拟环境：

deactivate

执行后，终端前面的 (.venv) 前缀消失，环境变量 PATH 自动恢复为系统默认状态。

如果该学习项目已经结束，或者在折腾过程中安装了不兼容的包导致环境损坏，彻底清理的方法非常简单粗暴：直接删除 .venv 文件夹即可。无需执行繁琐的卸载命令，系统全局环境完全不受任何影响：

# macOS / Linux 下删除
rm -rf .venv

# Windows PowerShell 下删除
Remove-Item -Recurse -Force .venv

自学者常见疑问与实用建议

1. 代码编辑器（如 VS Code / PyCharm）怎么识别虚拟环境？

很多自学者在终端里创建了虚拟环境，但在 VS Code 运行代码时依然报 ModuleNotFoundError。这是因为终端和代码编辑器内部选中的 Python 解释器是分离的：

VS Code：按快捷键 Ctrl + Shift + P（macOS 为 Cmd + Shift + P），输入 Python: Select Interpreter，在列表中选择带有 ('.venv': venv) 标识的项目解释器；或者直接点击右下角状态栏显示的 Python 版本号进行切换。
PyCharm：打开 Settings (Preferences) -> Project: demo_project -> Python Interpreter -> 点击齿轮添加本地解释器，选择现有目录下的 .venv/bin/python 或 .venv/Scripts/python.exe。

2. 为什么不能直接把虚拟环境文件夹移动或改名？

虚拟环境创建时，.venv/bin/activate 脚本以及可执行程序内部写入了当前目录的绝对物理路径。如果你把包含 .venv 的上层文件夹重命名或移动到其他磁盘路径，内部的绝对路径将会断裂失效，再次调用 python 时会提示找不到解释器。如果确实需要挪动项目位置，最规范的做法是在移动后直接删除旧的 .venv 目录，并在新路径下重新运行 python -m venv .venv 并执行 pip install -r requirements.txt。

3. 每次新建项目都要重新安装基础包，会浪费硬盘空间吗？

自学阶段通常练习项目安装的常用纯 Python 库（如 requests, flask）体积都在十几 MB 以内，现代硬盘空间完全足以容纳。而且 pip 本身拥有本地缓存机制（Cache），重复下载相同版本的轮子包（wheel）时会直接命中本地缓存，无需重复消耗网络流量。相比于未来因全局包冲突而浪费数小时排查 bug，这点磁盘空间的开销微不足道。

总结

在 Python 学习初期就建立起使用虚拟环境的习惯，不仅能从根本上杜绝版本冲突和系统环境污染，更是未来走向专业开发、参与开源项目和团队工程协作的基础内功。牢记这套极简口诀：“一项目一目录，进目录建 venv；见前缀再运行，留 txt 不留环境”，你的 Python 自学之路将少走绝大多数关于环境配置的弯路。