一次「成功」的部署，顶掉了两个在跑的服务

部署日志全绿，返回一个 shareLink，控制台显示发布成功。

我随手打开另一个页面检查——404。

再开一个——404。

只有刚发布的那一个活着。而这一个，之前是好的。

现象：发布不是「新增」，是「覆盖」

我手上有一个域名，上面跑着三个东西：

1. 一个公开的领货页（买家付款后凭链接取货，无密码）
2. 一个带密码门的总控台（我自己每天看数据）
3. 一个刚做完的答题页（准备上线）

第三个做完，我按流程发布，拿到 shareLink。我默认它是「新增一个链接」。

实际上不是。同一个账号下的所有应用共用同一个域名，不管发布哪个目录，拿到的 shareLink 都是同一个。

所以那一次发布的真实语义是：把这个域名整体指向了新目录。原来那两个，直接从线上消失。

为什么「知道」也没用

这条规则我之前就知道，也写过。但依然踩了。

原因很具体：发布这个动作的即时反馈是正向的——成功、绿字、有链接。没有任何一个信号提示我「你刚刚覆盖了别人」。

认知上我把它归到了「新增」那一类，而系统把它实现成了「覆盖」。这种语义错配，靠记忆是防不住的，只能靠发布前的强制检查。

顺带说一个更隐蔽的后果：旧引用不会自己消失。

总控台有一个定时推送，每 30 分钟往域名上同步一次数据。域名被顶掉之后，这个推送开始失败——连续失败 39 次，每次间隔 30 分钟，持续了 19.5 小时。

它不是不报错，是它的报错没有人看。一个后台任务的失败，静默地刷了 39 遍。

排查路径

按「现象 → 假设 → 验证」走，其实很快：

第三步一确认，根因就唯一了：不是三个服务里死了两个，是根路径换了主人。

修复：一个进程，多个路由

错误解法是「再发布一个目录把手脚找回来」——每次发布都会再覆盖一次，会变成打地鼠。

正确解法是让一个服务同时承接这三个入口，在同一个进程里做路由：

# server.py
#  GET /     -> 领货页（公开，无密码）
#  GET /dash -> 总控台（密码门）
#  GET /hh   -> 答题页（公开，无密码）

这么改之后：

• 三个入口共用一个域名、一个进程，发布不再互相顶掉
• 每次改动只更新 server.py，影响面可控
• 密码门从「另一个域名」变成「另一个路由」，反而更好管理

代价是路由表要自己维护，新增页面要记得加一条。但比「上线一次掉两个服务」便宜太多。

可以直接抄走的检查清单

发布任何「给外部用的入口」之前，问三个问题：

1. 这个发布动作是新增还是覆盖？ 别用直觉，去看文档里对 shareLink 的定义。
2. 现在这个域名上跑着什么？ 尤其是那些「不常打开、但别人可能正在用」的页面。
3. 有哪些外部引用指向它？ 定时任务、回调地址、已经发给别人的链接——这些不会因为你的发布而更新，只会静默失败。

再加一条工程习惯：任何后台任务的失败都要有人看。我这次真正的损失不是那 19.5 小时，是那 39 次失败里，没有一次把我叫醒。

同一个坑我踩了两次，第一次顶掉了总控台，第二次顶掉了前两个。两次根因一模一样。写下来，希望你别踩第三次。