远程配置入口 · 让 App 不发版也能改地址
前面几页的 indirection，目标都在服务端，你随时能改。但有一类载体一旦发出去就改不动了——印出去的二维码、已经装在用户手机上的 App、烧进设备的固件。其中写死的地址，事后想换，代价非常高：App
要重新发版、过审、还得等用户更新（而总有人永远不更新）。于是同一招再用一次：App 里不写死真实地址，只写死一个稳定的入口 id vega.link/s/help，真实地址放服务端配置，要改改一行。
这正是 rule + dispatch 的另一种动机：rule 那张「help → 真实 url」的表挪到服务端后，「改地址」就和「App 发版」彻底分了家。下面两台 App 并排——一台把帮助地址直接写死、一台只写死 /s/help，试着让帮助中心改版，看谁还能打开、谁成了死链。
这一层把「改地址」从「发版」里解放了出来。 帮助中心换路径、甚至整个迁到第三方换了域名，你只动服务端配置表一行，所有已经装出去的「新办法 App」下一次点击就跟到新地址——不发版、不过审、不挑用户版本。而「老办法 App」里那条写死的 url 一旦失效，唯一的补救是发新版并等待用户更新，在那之前点进去就是死链。
1 · 同一招的其他化身
凡是「载体发出去就改不动、但它指向的目标会变」，都适合加这一层：
- 印刷品二维码 / 海报： 印出去就定死了——所以二维码里放短链入口而非真实活动页，活动换地址改后台即可（见短链页）。
- 固件 / IoT 设备： 设备里写死「配置服务器入口」，真实后端地址、OTA 包地址全从那里取，换后端不用召回设备。
- 已发出的邮件 / 短信链接： 同样指向
/s/:code入口，而不是把当时的落地页 URL 固定写进正文。 - App Store 审核期： 审核要几天、紧急改文案 / 地址等不起，把可变的部分做成服务端下发，审核期内也能调。
- DNS 是这一层最早的实例： 程序连「域名」这个稳定名字，真实 IP 换了改 DNS 记录即可，客户端代码一个字不用动。
##「App 写死真实地址」vs「App 写死 /s/:id」
| 维度 | App 里直接写死真实 url | App 里只写死 /s/help |
|---|---|---|
| 改地址 | 改 App 代码 ✗ | 改服务端配置一行 ✓ |
| 生效范围 | 只有装了新版的用户 ✗ | 所有版本立刻跟随 ✓ |
| 发版 / 过审 | 每次改地址都要走一遍 ✗ | 无需发版 ✓ |
| 老版本用户 | 不更新就一直是死链 ✗ | 不更新也能跟到新地址 ✓ |
| 点击统计 | 拿不到（直连目标） | 入口处天然能记 ✓ |
| 代价 | 无（但债留给未来） | 多一跳 + 一张配置表要维护 + 入口故障则全部失效（需要回退方案） |
注意那条代价：入口成了单点——服务端这张表故障，所有 id 一起失效。所以真实系统常给 App 留一份内置默认地址（拉不到配置就用打包时的默认值），把「可变」和「可用」都顾上。
2 · 相关页
- 本系列 · 为什么要有路由这一层——本页是「indirection 力量」在客户端发版周期这根轴上的极端体现：载体改不动，就让它指向的目标可改。
- 本系列 · 短链接为什么会存在——同样是
/s/:code入口，但短链的动机是「长 URL 人用不了」的长度问题；本页的动机是「写死的地址改不动」。 - 本系列 · 分享地址统一入口——同样把流量收到一个服务端入口，share 主打多渠道统计与安全，本页主打解耦发版。三者共用同一套
/s/:code+ 服务端查表骨架。