用户点了商品链接，但手机里还没装 App，安装完以后为什么还能回到刚才那件商品？

做增长功能的时候，最开始的思路很简单：做个 Deep Link，用户点链接直接跳转到 App 里的对应页面。

跑了一段时间发现问题：用户手机里根本没装 App，点链接直接白屏了。好不容易来了个用户，结果连 App 都没装，直接流失了。

这时候才意识到：普通 Deep Link 只解决了"装了 App 的用户怎么跳"，没解决"没装 App 的用户怎么转化"。延迟链接就是干这个的。

一、普通 Deep Link 和延迟链接有什么区别

先把概念理清楚：

类型	已安装	未安装
普通 Deep Link	直接跳对应页面	白屏/错误
延迟链接	直接跳对应页面	跳应用市场，安装后自动恢复

延迟链接的完整流程是：

1. 用户点链接；
2. 系统判断 App 装没装；
3. 装了就直接跳对应页面；
4. 没装就跳应用市场下载；
5. 安装完第一次启动，自动跳回原来的页面。

用户的感觉是：我点了个商品链接，下载安装完，打开 App 直接就是那个商品。完全无感。

二、安装后路由恢复是怎么实现的

很多人好奇：App 刚安装，第一次启动，系统怎么知道我刚才点的是哪个商品链接？

这就是延迟链接的核心机制。链接信息存在云端，App 启动的时候去拉取，然后根据这个信息做路由。

这段代码解决什么问题： 首次启动时恢复延迟链接路由。
文件： pages/EntryAbility.ets
用途： 安装后路由恢复
接入位置： 应用启动流程

import appLinking from '@ohos.app.appLinking';

async onCreate() {
  // 获取延迟链接数据
  const deferredLink = await appLinking.getDeferredLink();
  if (deferredLink) {
    const uri = deferredLink.uri;
    // 根据 URI 做路由跳转
    this.routerToProductPage(uri);
  } else {
    // 正常进首页
    this.routerToHomePage();
  }
}

这里最容易踩的坑就是：只判断有没有链接，不做参数校验。链接参数直接信任，万一被人篡改了，安全问题就出来了。

三、四种场景分别是什么样的

我们来测一下四种场景：

场景	跳转结果
已安装，未登录	直接跳商品页
已安装，已登录	直接跳商品页
未安装，未登录	跳应用市场，安装后进首页
未安装，已登录	跳应用市场，安装后直接进商品页

我原以为：未安装的用户安装完，应该都先进首页。结果不是，登录状态下的用户，安装完直接就回到商品页了。

四、参数校验为什么很重要

还有个安全问题：链接参数不能直接信任。

错误做法	风险
链接里的 ID 直接用	被人篡改了
不校验链接有效期	过期链接还能跳
不校验内容是否下架	跳到不存在的页面

正确的做法是：拿到链接参数之后，先在服务端校验一下，确认这个内容还存在，再跳转。不要直接拿参数就跳。

五、路由恢复为什么会重复执行

还有个容易踩的坑：路由恢复重复执行。

很多人在 onCreate 里恢复路由，在 onNewWant 里也恢复，结果就是：用户点一次链接，跳了两次页面。

正确的做法是：做个标记，恢复过一次就不要再恢复了。或者根据启动模式判断，冷启动和热启动分开处理。

六、几个容易踩的坑

第一个坑：把 Deep Link 和延迟链接当成一回事。普通 Deep Link 解决不了未安装的问题。

第二个坑：安装后只进首页不恢复业务页面。用户点了链接下载，结果打开是首页，流失了。

第三个坑：链接参数直接信任。不校验，安全问题。

第四个坑：路由恢复重复执行。一次跳转，跳了两次页面。

第五个坑：链接过期或目标内容下架没有兜底。跳到不存在的页面，白屏。

这次做增长链接最大的体会是：延迟链接不是"多跳一步"这么简单，是一整套完整的转化链路。从点链接、判断安装状态、下载、安装、启动、恢复路由，每一步都要想清楚。用户的体验应该是无感的——点了就下载，下完打开就是我刚才看的东西。