半夜给自己的小项目部署代码，卡住的地方完全没想到

上周五晚上十点多，我在给自己业余搭的一个小系统部署代码。这东西说白了就是个人版的"记忆管家"：把我平时踩过的技术坑、做过的判断、临时起意的想法，自动归类存起来，需要的时候能检索出来用，不用每次都从头把背景讲一遍。跟公司项目没关系，纯粹是我自己业余捣鼓的一个工具，做出来主要是给自己用。

选技术方案那会儿我算过一笔账：AI 模型没选国外那几家大厂的，选了国内的；数据库也没新开一个，服务器上原本就有一套 PostgreSQL，直接接上去用。理由很朴素——业余项目，我自己掏钱，长期跑下来，调用成本和网络能不能连上，比"哪个模型更聪明"更要命。这笔账我当时觉得算得挺明白。

结果部署那天，省下来的钱换了个名字，找上门来了。

先是构建卡住了。我在服务器上敲了一条常见命令，把构建过程扔到后台跑，指望它自己完事，我隔一会儿回来看结果。可命令刚发出去，连接本身就断了——不是构建失败，是这条 SSH 连接自己在几十秒到几百秒之间掉了线，跟后台那个进程没关系。我一开始以为是网络抽风，试了两次都一样。后来把方式改成老老实实守在前台等、把超时时间设得足够长，问题才算过去。这个坑背后的机制我到现在也没完全搞懂，大概率是子进程和父进程的输出没分离干净，但至少摸清了规避的办法。

第二个坑更折腾人。构建过程里安装依赖包那一步，卡了整整五分钟，屏幕上一行字都不动。我脑子里第一反应是"服务器网络又抽风了"，试着用 curl 探测了一下，结果对方接口老老实实返回了 200——网络其实是通的。翻了半天才发现，是某几个包从默认源那边，隔三差五就是连不上，不是彻底断，是"看运气"。换成国内的镜像源重新装了一遍，几十秒就装完了。

回头看这两个坑，跟我最初选型时打的那笔省钱账，其实是同一笔账的另一半。选国产模型、复用现成数据库，图的是订阅费和调用成本这些看得见的钱；可部署那晚我耗掉的时间——半夜盯着一个不动的进度条，来回猜是网络还是代码的问题，这笔账当时压根没算进去。省下来的不是钱，是把这部分成本从"账单"挪到了"我自己的晚上"。

这也不是说选型选错了，长期来看那笔省下来的钱是真省下来的。只是我以后再给自己的项目挑技术方案，会顺手多问自己一句：这条路走下去，部署那天大概率要自己扛几个坑？至于这笔隐性账到底值不值，得等我下一次再上手部署一个新东西的时候，看看踩坑的频率有没有降下来，这事我现在只能说，值得盯一阵子。