App 里看不见的路由
路由也存在于没有地址栏的地方。点一条链接直接跳进 App 的某个页面而不是首页，这叫 deep link。它面对一道天生的分叉：装了 App 就进 App，没装就退回网页或去商店。同一条链接要让两种用户都不落空，这是 deep link 路由设计的全部难点。
1 · 两种链接形态的取舍
| 维度 | 自定义 scheme（myapp://） |
Universal Link 与 App Link（https://） |
|---|---|---|
| 谁来接 | App 注册了该 scheme 才有人接 | 系统按域名归属表把 https 路由进 App |
| 没装 App | 无人响应，报错或白屏 | 就是一条普通网址，照常开网页 |
| 归属校验 | 任何 App 都能抢注同名 scheme，易被劫持 | 靠服务器上的关联文件双向验证 |
| 体验 | 可能先闪一下浏览器 | 系统层直接进 App，不闪 |
| 配置成本 | 低，App 端声明即可 | 高，要在域名上部署关联文件 |
两个平台各有自己的关联文件：iOS 的 Universal Links 读 apple-app-site-association，Android 的 App Links 读 assetlinks.json，两者都放在站点的 /.well-known/ 目录下，由系统在安装或首次访问时抓取校验。
注 · 最棘手的是没装 App 的新用户：既想让他去商店安装，又想让他装完直接到原本想去的那个页面而不是 App 首页，这叫 deferred deep link（延迟深链）。做法是落地网页先把目标（如 product/42）暂存到剪贴板、设备指纹或服务端配对记录里，再引导去商店；App
首次启动时读回这个目标并路由过去。归因 SDK 的核心工作就是这件事。
2 · 内核仍是路径匹配
deep link 看着特殊，内核和前几页一样：myapp://product/42 或 https://vega.link/product/42 里的 product/42 就是一条 path，App 内部同样有一张路由表把它匹配到对应的页面组件并提取出 id = 42，与匹配引擎是同一套机制，只不过这张表跑在 App 里、对用户不可见。而「装了走 App、没装走网页」这道分叉，本质是一次按条件选择目标的路由决策。
真实分享入口常先判 User-Agent，手机走 deep link、桌面走网页，那是统一入口在多端上的分流。