部署是玄学：同样的命令，今天能跑昨天不行

每个做过部署的人都经历过这样的时刻：昨天还能跑的流水线，今天同一段代码、同一个命令，忽然就红了。你什么都没改——至少你认为是这样。

然后你开始排查。这是整个流程里最荒诞的部分。

第一步：怀疑自己

你打开 git log，反复确认最近确实没有新的提交。你甚至开始怀疑，是不是有人在深夜偷偷 push 了代码。查了一遍又一遍，结论是：没有。

于是你开始怀疑记忆。也许昨天它根本没绿过？你翻出截图，它确实是绿的。截图不会骗人——除非截图是 AI 生成的。

第二步：怀疑环境

npm install 装依赖时，网络超时了。可昨天也是这个网络。你 ping 了一下 registry，通了；再 npm install，又卡住了。

你开始相信，网络的连通性是一种量子态——它在你观测它的时候，坍缩成「通」或者「不通」。

$ npm install
# 这行注释没有任何信息量，但它让日志看起来像是有人在工作
npm ERR! network request to https://registry.npmjs.org/ failed

第三步：怀疑人生

你终于定位到问题：一个昨天还在的依赖包，今天被作者 yank（下架）了。不是你的错，也不是环境的错，是一个陌生人在世界的某个角落，决定下架一个 0.0.1 版本的包，而你的 lock 文件里恰好锁着它。

结论

部署之所以是玄学，是因为它站在一条由无数第三方构成的脆弱链上：DNS、镜像源、依赖包、CI 平台、服务器、证书……任何一个环节的「微小变化」，都会让「同样的命令」产生不同的结果。

我们能做的，不是消除玄学，而是让玄学变得可观测：锁定依赖版本、固定基础镜像、记录每一次构建的输入。当玄学再次发生时，至少你知道该从哪一层的哪一行开始怀疑。