5.3 深层链接与两端导航集成

5.3 深层链接与两端导航集成

本节摘要：深层链接让系统桌面、短信、网页里的一枚链接直达应用内的指定屏幕，是拉新、分享、运营推送的技术底座。本节讲清两端入口机制的关键差异（自定义协议的确认弹窗与校验型链接的无感直达）、链接到屏幕的映射配置，以及「应用未安装时链接落在哪」的降级闭环。本节是导航篇的出口：门打开了，应用才算接入外部世界。

从一条分享链接说起

场景：用户把应用里的一件商品分享到群聊，好友点开链接。此时会发生什么？答案取决于三件事：好友装没装这个应用、链接用的什么入口类型、操作系统信不信任这次唤起。理想体验是「装了直达商品页、没装落在商品网页」，而现实里两端各自设了门禁——iOS 与 Android 都不允许应用随意被唤起，除非链接与应用完成「认亲」。这套认亲机制就是本节的主线。

入口类型分两类。第一类是自定义协议：应用注册一个专属协议名，链接长成「协议名加路径」的形式，系统见到就询问用户是否打开。实现简单，但体验有折扣——iOS 上首次唤起会弹确认框，Android 上未做校验时会弹出应用选择器，分享场景里每一道弹窗都在流失用户。第二类是校验型链接（iOS 的通用链接与 Android 的应用链接）：链接就是普通网址，应用通过在网站根目录放置关联声明文件、并在应用工程里登记关联域名，向系统证明「这个域名归我」。验证通过后，装了应用的用户点击链接直接无感进应用，未安装的用户自然落在网页——同一个链接两种归宿，这是分享与拉新场景的标准答案。

图：一枚链接的完整旅程与降级闭环

配置：把映射表交给导航容器

认亲配置完成后（应用工程登记关联域名、网站放好关联声明，两端各做一遍），剩下的就是把「网址路径到屏幕」的映射交给导航容器。框架的链接配置把映射表集中声明，路径参数自动变成路由参数——5.2 的参数纪律在这里兑现：链接里只有定位信息，屏幕凭标识取数：

const linking = {
  // 声明应用认领的入口：自定义协议与校验域名
  prefixes: ['bloomapp://', 'https://bloom.example.com'],
  config: {
    screens: {
      // 网址路径 映射到 屏幕与参数
      Detail: 'product/:id',
      Home: 'home',
      Editor: 'write/:draftId?',
    },
  },
};

function App() {
  return (
    <NavigationContainer linking={linking} fallback={<Splash />}>
      {/* 导航结构照旧 */}
    </NavigationContainer>
  );
}
​

配置生效后，无论应用是冷启动还是已在后台，系统送进来的链接都会被解析成跳转指令——冷启动场景框架会等导航树就绪再执行跳转，这也是 2.3 节启动流程的一个实际落点：深链用户的首屏是目标屏而非首页，启动路径上任何多余的初始化都会直接拖慢这次「第一印象」。

完整案例：拉新活动链接的闭环建设

背景：市场部策划邀请裂变活动：老用户分享专属链接，新用户点击后安装并注册，双方都要拿到奖励，且新用户首启应直达被分享的内容页。操作：链接采用校验型域名承载，双端完成认亲配置；未安装用户落在活动网页，网页引导安装并尽力保留分享上下文；新用户完成首启后，应用读取安装来源中的上下文，恢复原路直达内容页并完成奖励归因；运营位、推送、短信三个渠道统一走同一映射表，避免各渠道各配一套路径。结果：分享到首启直达的转化漏斗每一层都有了数据，闭环建立前「装了但没看到」的流失段被显性化并压缩。解读：这个案例里技术占比其实不大——认亲配置照文档做，映射表十行——真正的工程量在「闭环思维」：链接不是终点而是漏斗，每个分叉都要有归宿。变式：若业务还要支持「网页内一键唤起」，再叠加自定义协议作为校验失败时的降级通道即可，弹窗损耗由校验型链接的主通道兜住。

调试手法与检查清单

深链配置的麻烦在于「链条长、两端各半」，调试要分段验证而不是一上来就在真机上点链接。分段清单如下：第一段，映射验证——不经过系统，直接在应用内模拟一条链接交给导航容器的链接配置解析，确认能解出正确的屏幕与参数；这一步过了，说明映射表没问题。第二段，认亲验证——分别用两端系统提供的校验状态查看手段确认关联声明生效，iOS 侧验证应用的关联域名授权状态，Android 侧验证应用链接的自动验证结果；这一步常见失败是网站声明文件返回的不是预期格式（被网关改写、缓存过期），或者是域名配置了跳转导致校验失败。第三段，真机端到端——把链接发到聊天工具里点，验证冷启动直达与热启动直达两条路径；「热启动直达正常、冷启动直达失败」说明映射没问题而启动时序有问题（链接跳转发生在导航树就绪前），按 2.3 的启动口径排查。

日常迭代还有两条维护性提醒。其一，映射表是「契约资产」，新增屏幕顺手登记映射、废弃屏幕同步清理，深链路径的 404 与网页一样丢人。其二，参数要经得起「外部构造」——深链参数来自应用外，可能缺失、畸形、恶意超长，目标屏幕对参数做与接口返回同级别的校验，这条安全提醒会在 8.4 再见到一次。

与推送、分享位的协同

深链很少单独工作，它通常是推送与分享的执行末端。推送点击打开指定页，本质是把推送载荷里的一条路由变成深链跳转——这带来一个集成决策：推送模块不要自己解析目标页，统一转成链接交给导航容器的映射层处理，路由规则只有一份，推送、扫码、分享三个入口天然一致。分享链路则要注意「链接的生成端」与「消费端」用同一张映射表的反向推导：分享时根据屏幕与参数生成规范链接，避免每个业务手拼字符串拼出五花八门的路径。把「链接即路由」立成全应用的统一抽象，深链就从「一个功能」升格为「路由的对外形态」——这是本章骨架、血脉、门路三条线的最后合流。

本节要点回顾

• 两类入口：自定义协议有弹窗损耗，校验型链接无感直达且未装落网页，是分享场景的正解；
• 认亲是双向的：应用登记关联域名，网站放关联声明，两端各配一遍缺一不可；
• 映射表集中声明：路径到屏幕的转换交给导航容器，参数自动注入；
• 深链首屏即目标屏：冷启动直达对启动性能更敏感，多余初始化直接伤害转化；
• 延迟认亲闭环：安装后首启恢复原路，拉新链接才算走完漏斗。

导航篇完结，应用已经「骨架通、血脉通、门路通」。下一章进入修行深处：性能优化与调试，让快不只是感觉。