如果你用 Python 做过项目，你一定经历过这种绝望：
昨天还能跑的代码，今天突然挂了。排查半天，发现是某个依赖包发布了新版本，引入了不兼容的改动。你甚至不知道是什么时候升级的 —— 毕竟 requirements.txt 里只写了包名，没写版本号。
pip 26.1 终于要解决这个痛点。
🔒 Lockfiles：锁定每一个依赖
新版本的 pip 引入了 pip lock 命令。运行之后，它会生成一个 pylock.toml 文件，里面精确记录了每一个依赖的版本号、哈希值、下载地址。
这意味着什么？
可复现的构建。无论在什么环境、什么时间运行，你得到的依赖都是完全一致的。不再担心"在我机器上能跑"的尴尬。
确定性的部署。生产环境、测试环境、开发环境，三者完全一致。告别因为环境差异导致的诡异 bug。
安全的审计。每一个依赖都有哈希校验，防止供应链攻击。如果下载的文件被篡改，pip 会立即报错。
Simon Willison 在他的博客里展示了一个例子：安装 Datasette 和 LLM 两个包，生成了一个 519 行的 lockfile。这意味着什么？这两个看似简单的包，背后依赖了数百个其他包。没有 lockfile，你根本不知道自己的项目有多脆弱。
⏱️ 依赖冷却期：给升级踩刹车
pip 26.1 还引入了一个更有趣的功能：依赖冷却期（dependency cooldown）。
通过 --uploaded-prior-to P4D 这样的参数，你可以告诉 pip："只安装 4 天前发布的版本"。
这有什么用？
避开新鲜 bug。新发布的版本往往有未发现的 bug，等几天让社区踩坑，你再升级会更安全。
可控的更新节奏。你可以设定策略：生产环境只用发布超过 7 天的版本，测试环境可以用 3 天前的，开发环境可以追最新。
回滚的缓冲期。如果某个版本有问题，你有时间发现并阻止它进入生产环境。
Simon 演示了一个例子：LLM 0.31 是三天前发布的，使用 --uploaded-prior-to P4D 会安装 0.30 版本。这种精确的版本控制，在以前是很难实现的。
🐍 Python 3.9 的告别
pip 26.1 还做了一件事：放弃对 Python 3.9 的支持。
Python 3.9 在 2025 年 10 月已经停止维护，但 macOS 仍然把它作为默认的 Python 版本。这导致很多 macOS 用户还在用已经过时的 Python。
pip 的这个决定，某种程度上是在推动生态向前。毕竟，安全更新都没了，还留着干嘛？
💡 对 Python 开发者的建议
如果你还在用传统的 requirements.txt，是时候考虑升级了。
新项目：直接用 pip lock 生成 lockfile，把它提交到版本控制。
老项目：逐步迁移，先用 lockfile 锁定当前状态，再慢慢优化依赖版本。
生产环境：结合 --uploaded-prior-to 参数，建立依赖更新的缓冲机制。
Python 的依赖管理一直被诟病不如 npm、cargo 这些现代工具。pip 26.1 的发布，让我们终于看到了追赶的希望。
毕竟，确定性的构建是工程化的基础。没有这个基础，再厉害的代码也只是空中楼阁。
