Python解释器升级/降级后安装requirements.txt是否安全？

核心结论 #

不管是从Python3.6升级到3.8，还是反向降级Python版本，直接执行pip install -r 旧requirements.txt都没有安全保证，大概率会遇到安装失败或者运行报错的问题。 #

为什么升级到Python3.8直接装旧requirements不安全 #

你之前通过pip freeze > requirements.txt导出的依赖列表，是完全绑定原Python3.6运行环境的，存在两层不兼容风险：

• 平台编译层不兼容：大量带C/C++扩展的第三方包（比如numpy、pandas、Pillow、lxml等），PyPI上分发的预编译wheel是严格匹配Python版本的，对应cp36版本的wheel无法在3.8解释器上运行。如果旧requirements里锁定的包版本已经停止维护、没有发布适配Python3.8的预编译包，pip会自动拉取源码尝试本地编译，缺少编译环境的话会直接安装失败。
• 运行时不兼容：哪怕部分包的旧版本能在3.8上安装成功，也不代表功能正常。Python3.8对语法、标准库接口做了不少调整（比如废弃了部分旧的asyncio接口、调整了urllib的默认行为、新增语法规则可能和旧包的代码产生冲突），没适配3.8的旧版本包在实际运行时会触发报错。

反向降级Python版本用旧requirements为什么同样不可行 #

降级场景的兼容性问题甚至更多：

• 你之前在Python3.6环境下通过pip安装的包，很多当时的版本已经提高了最低Python要求（比如要求最低支持Python3.6），你把解释器降到3.5及更低版本时，pip会直接检测到版本不匹配，拒绝安装对应版本的包。
• 对应包的预编译wheel同样不会提供比原Python版本更低的cp版本包，源码编译的失败概率比升级场景还要高。

正确操作流程 #

不管是升级还是降级Python版本，都不要直接硬套旧的依赖文件：

• 第一步直接删除旧的venv虚拟环境文件夹，在新的Python版本下重新创建干净的虚拟环境，不要复用旧虚拟环境（旧虚拟环境的解释器路径是硬编码绑定原Python版本的，根本无法跨版本使用）。
• 第一次安装时不要用全锁定的pip freeze导出文件，先整理出项目实际需要的核心依赖范围，让pip在新的Python版本下自动解析适配的兼容版本。
• 项目所有功能跑通、测试完成后，再通过pip freeze > requirements.txt导出当前新环境的依赖列表，作为后续的版本锁定文件。
• 如果需要同时兼容多个Python版本，写依赖时不要用全精确版本锁定，改成范围指定（比如numpy>=1.19.5,<2.0.0），给pip留足跨版本的依赖解析空间。

内容的提问来源于stack exchange，提问作者bavaza