2.4 包管理与虚拟环境

2.4 包管理与虚拟环境

本节摘要：第三方库靠 pip 安装，而每个项目需要的库和版本常常互相冲突——虚拟环境给每个项目一间独立的"依赖小房间"。本节讲清 pip 的常用操作、虚拟环境的创建与激活、requirements.txt 的导出与还原，最后给轻记账建一间自己的环境。这间小房间会在第 6 章跟着项目一起搬上服务器，是全书工程化的第一块基石。

读完这节能做什么

阅读完本节，你应当能够：

1. 用 pip 安装、升级、卸载第三方库，查看已装清单
2. 解释为什么全局安装会引发版本冲突
3. 创建、激活、退出虚拟环境，在新环境里还原依赖
4. 导出并使用 requirements.txt 让项目"带着清单走"

问题：两本书抢同一个书架

想象一个场景：你半年前写了个爬虫项目，依赖某解析库的 4.0 版；今天轻记账要用同一个库，但新功能需要 5.0 版。库默认装在 Python 全局目录，同一个包同一个位置——装了 5.0，老项目当场歇菜。这不是假设，是所有 Python 开发者都会踩的坑。解法朴素而有效：给每个项目配一套独立的已安装库，互不干扰。这套机制就是虚拟环境。

图 2-4 虚拟环境：每个项目一间独立房间

pip：装库的命令行工具

pip install requests          # 安装
pip install "requests==2.31.0"  # 安装指定版本
pip list                      # 查看已装
pip show flask                # 看某个库的详情
pip uninstall requests        # 卸载
​

装完的库立刻可以 import。装之前可以在包索引网站看看下载量、最近更新时间和文档质量——下载量小、三年没更新的库慎用，2.3 节说的"成熟度尺子"在安装这一步就派上用场。

虚拟环境：创建、激活、退出

现代 Python 自带 venv 模块，三步搞定：

# 第一步：在项目文件夹里创建环境（会生成一个 .venv 文件夹）
python -m venv .venv

# 第二步：激活（Windows 与 mac/linux 命令不同）
# Windows PowerShell：
.venv\Scripts\Activate.ps1
# mac / linux：
source .venv/bin/activate

# 第三步：想退出时
deactivate
​

激活成功的标志是终端提示符前面多了个 .venv 前缀。此后 pip 装的一切都进这个文件夹，与全局和其他项目彻底隔离。验证一下：激活后运行 pip list，会发现干干净净只有几个基础包——这间小房间是空的，随你装修。

requirements.txt：带着清单搬家

环境建好、库装完，把这个项目的依赖清单导出成一份纯文本：

pip freeze > requirements.txt
​

文件内容形如：

flask==3.0.2
sqlalchemy==2.0.30
​

任何一台新机器（同事的电脑、第 6 章的云服务器）都能一键复刻同样的环境：

python -m venv .venv
# 激活后：
pip install -r requirements.txt
​

这份清单的真正价值在第 6 章爆发：部署的本质就是"在一台陌生机器上原样复刻你本地的运行环境"，requirements.txt 就是复刻说明书。现在养成"装完库就 freeze"的习惯，将来部署时省去一半报错。

演练：给轻记账建环境

从头走一遍完整流程：

# 1. 进入项目文件夹，创建环境
python -m venv .venv
# 2. 激活（按你的系统选命令）
# 3. 安装本章和后续章节会用到的库
pip install flask sqlalchemy
# 4. 冻结清单
pip freeze > requirements.txt
​

然后做一个"破坏性验证"加深理解：退出环境（deactivate），在全局装一个冷门小包，再激活环境运行 pip list——那个包不在列表里。两套世界互不可见，这就是隔离的直观感受。变式一：删掉整个 .venv 文件夹，凭 requirements.txt 从零重建，练熟"环境可抛弃"的心态——环境坏了重建就是，代码才是资产。变式二：思考一个问题：.venv 文件夹该不该进入 Git 仓库？答案在下一章讲 Git 时揭晓。

依赖安装失败的三种常见情形

pip 不是每次都一帆风顺，三种典型故障提前认识。网络超时：默认源在国外，国内网络下载大包容易断，临时提速的办法是安装命令后加镜像源参数，把下载指向国内镜像站；长期生效则把镜像地址写进 pip 配置文件，一次设置终身受益。版本冲突报错：装 B 库时提示"需要 C 库某版本，但已安装的是另一版本"——这多半是误装到全局的时刻发生的，先确认提示符前缀还在虚拟环境里；若环境内部真的冲突，删掉 .venv 重建，凭清单重装一遍干净环境。编译失败：少数带 C 扩展的库在 Windows 上需要编译工具链，新手对策是优先选纯 Python 实现或官方提供预编译包的库；真绕不开时按报错提示装构建工具，或用 6.4 节的容器方案把编译环境一并打包。

还有一个值得养成的习惯：装完新库随手 pip list 扫一眼版本号，并与官方文档核对兼容范围。框架类库的大版本升级常伴随接口变化，轻记账将来从旧版框架升到新版时，这份"版本敏感性"能帮你提前预警，而不是等报错堆成山再回头考古。

易错点清单

• 没激活就 pip install：库装进了全局，白装还污染环境，先看提示符有没有 .venv 前缀
• 激活命令平台混淆：Windows 用反斜杠路径的 Scripts，mac/linux 用 source 加 bin
• requirements.txt 凭记忆手写：版本号写错导致复刻失败，永远用 pip freeze 生成
• 把 .venv 当项目文件备份：环境可随时重建，真正要进版本库的是代码和清单

本节要点回顾

• pip 管安装，install、list、unfreeze 三板斧够日常
• 虚拟环境隔离依赖，每个项目一间房，版本冲突从此绝迹
• requirements.txt 是环境快照，pip freeze 生成、pip install -r 还原
• 环境可抛弃，代码是资产：坏了就删了重建
• 这份清单将在第 6 章部署时复用，现在养成冻结习惯

依赖住进了独立房间。下一章暂不加功能，专心塑形：面向对象、测试、Git，把 v0.2 锻造成真正的工程。