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