4、requirements.txt：生成、安装与版本控制

说实话，requirements.txt 这东西，看着简单，坑可不少。我见过太多团队因为一个版本没锁死，导致线上环境炸锅。今天咱们就把它彻底聊透。

生成这个文件，说白了就是把当前环境里装的包都列出来。我个人习惯用 pip freeze，简单粗暴：

pip freeze > requirements.txt

跑完这条命令，你会看到类似这样的输出：

ansible==4.3.0
cryptography==3.4.8
Jinja2==3.0.1
netmiko==3.4.0
paramiko==2.7.2
PyYAML==5.4.1

嗯，这里要注意。直接 pip freeze 会把所有包都列出来，包括那些依赖包。你想想看，有时候你只想记录顶层依赖，这时候可以用 pipreqs：

pip install pipreqs
pipreqs ./ --encoding=utf-8

它会扫描你的代码，只提取真正用到的包。我在项目中遇到过好几次，用 pip freeze 生成的列表里有一堆无关包，结果部署时反而出问题。

小技巧： 如果你用 pipenv 或 poetry，它们会自动管理依赖文件，不需要手动生成 requirements.txt。但说实话，在大多数网络运维场景下，还是 requirements.txt 最通用。

安装就一句话：

pip install -r requirements.txt

但这里有个坑。我曾经在部署自动化脚本时，发现同样的 requirements.txt，在不同机器上装出来的包版本不一样。为什么？因为 -r 参数只安装文件里列出的包，但如果某个包依赖另一个包，而那个依赖包没指定版本，pip 就会装最新版。

举个例子：

# requirements.txt
netmiko==3.4.0

Netmiko 依赖 paramiko，但你没锁 paramiko 的版本。结果机器 A 上装了 paramiko 2.7.2，机器 B 上装了 2.8.0。两个版本之间可能有 API 变化，你的脚本就炸了。

避坑指南： 我曾经因为没锁依赖版本，导致线上 20 台设备的配置批量下发全部失败。从那以后，我要求团队必须用 pip freeze 生成的完整列表，而不是手动写几个包名。

版本控制是 requirements.txt 的核心。说白了，就是告诉 pip：「你要装哪个版本，或者哪个范围内的版本」。

常见的写法有这几种：

我个人建议，在生产环境中尽量用 == 精确锁定。你想想看，网络设备配置下发这种操作，容不得半点差错。版本不一致导致的 API 变化，可能让你丢数据。

但开发环境可以灵活一点。比如：

# 开发环境
netmiko>=3.0.0, <4.0.0
paramiko>=2.7.0

这样既能用上新功能，又不会因为大版本升级而炸锅。

  核心原则： 生产环境锁死版本，开发环境放宽范围。但无论哪种，都要把依赖包的版本也锁住。

下面这张图，帮你理清 requirements.txt 的核心逻辑：

最后，给你几个我踩坑后总结的建议：

血的教训： 我曾经在升级 netmiko 时，没注意它依赖的 paramiko 也升级了。结果 paramiko 的新版本改了 SSH 密钥交换算法，导致 30 台老设备连不上。嗯，从那以后，我每次升级都先在测试环境跑一遍。

好了，requirements.txt 的核心内容就这些。记住一句话：版本锁死，环境一致，部署无忧。