未装App时，你的推广链接去哪了？

用户点了你的推广链接，手机却弹出一个404页面——这是Flutter开发者最不想看到的场景。前面六篇文章我们搞定了App内的深度链接捕获，但那个"App还没装"的空白地带，至今没人填上。

事件现场：404杀死转化率

假设Maria给João发了一个健身App的推荐链接，带她的邀请码。João点击时，手机里没有这个App。

没有跳转页的情况下，浏览器直接报错。邀请码丢失，João困惑离开，Maria的推广失效。三方全输。

这个场景每天都在发生。深度链接（Deep Link）的完整链路里，"未安装态"是最容易被忽略的断点。

解决方案是一页HTML：检测平台、尝试唤醒App、保存邀请码、失败则导去应用商店。本文是系列第七篇，补全这最后一块拼图。

正方：跳转页是必选项

支持方认为，没有这页HTML，整个深度链接体系就不完整。核心论据有三：

第一，用户体验连续性。跳转页给用户明确的视觉反馈——"正在打开FitConnect"，而不是冷冰冰的浏览器错误。页面可以展示品牌Logo、邀请人信息、甚至预览App内容，降低跳出率。

第二，数据不丢失。通过localStorage（本地存储）在浏览器里暂存邀请码，即使首次安装失败，用户从商店下载后打开App，代码仍在。这是延迟深度链接（Deferred Deep Link）的前置条件。

第三，平台适配统一。同一套HTML处理Android的Intent Scheme和iOS的Universal Link，开发者不用维护两套逻辑。代码根据UA字符串自动分流，维护成本最低。

原文给出的实现逻辑很直接：先存码，再尝试打开App，超时未响应则跳转商店。localStorage作为双保险——如果App直接唤醒成功，邀请码走深度链接协议；如果失败，下次启动从浏览器缓存读取。

反方：跳转页增加漏斗损耗

反对方质疑：多一层跳转，就多一层流失。他们的担忧同样具体：

加载时间成本。HTML页面再轻量，也需要DNS解析、TLS握手、资源下载。在弱网环境下，这1-2秒的空白足以让用户退出。对比直接跳转应用商店的方案，每一步额外操作都是转化率杀手。

浏览器兼容陷阱。不同厂商的WebView实现差异巨大。某些Android定制系统会拦截Intent Scheme，iOS的Universal Link在部分场景下需要用户二次确认。跳转页试图统一处理，反而可能引入新的兼容性问题。

localStorage的可靠性存疑。用户可能禁用第三方Cookie、使用隐私模式、或手动清理存储。把关键业务数据押在浏览器缓存上，存在单点故障风险。更稳妥的做法是把邀请码与设备指纹绑定在服务端，而非前端。

还有一个未被明说的成本：这页HTML需要独立部署和运维。对于小团队，多一个服务节点就意味着多一组监控、备份、SSL证书管理。收益是否覆盖成本，需要具体业务数据验证。

判断：跳转页是特定阶段的工具

双方都有道理，但适用场景不同。

如果你的产品处于增长期，依赖邀请裂变驱动获客，跳转页几乎是必选项。延迟深度链接的完整体验，能显著提升邀请转化率。原文系列的前六篇已经证明，Flutter生态可以支撑这套技术栈，第七篇只是补上最后一块。

但如果你的获客主力是付费广告、应用商店搜索优化，用户本就带着明确安装意图，跳转页的价值就大幅缩水。此时简化路径、减少漏斗层级，可能比"完美体验"更务实。

技术选型从来不是对错问题，是成本与收益的权衡。这页HTML的价值，取决于你的核心增长引擎是否依赖"用户带用户"。

原文作者没有给出量化数据，但留下了可验证的假设：localStorage + 深度链接的双轨方案，能否在真实场景下将邀请转化率提升到可接受水平？这需要A/B测试回答，而非技术辩论。

系列到此完结。从Dart结构到Android/iOS原生捕获，从Flutter通道到生产环境验证，再到延迟深度链接和跳转页——完整的深度链接技术栈已经摊开。下一步是把它放进你的业务场景里，看数据说话。

你的App里，有多少比例的用户是在未安装状态下首次接触推广链接的？这个数据决定了跳转页的优先级。