通用链接与深度链接：2026 完整指南
Source: Dev.to
计划
Universal Links 和 App Links 只有在四层正确对齐时才会工作。在本指南中，我们将逐一讲解：
你的域名
如何设置 AASA 和 assetlinks.json，让 iOS 和 Android 信任你的 URL。
你的移动应用
iOS 权限、Android 清单以及原生 URL 处理程序中需要包含哪些内容。
你的托管或框架
Next.js、Firebase、Vercel 等平台如果重写或重定向文件，可能会导致 Universal Links 失效。
客户端逻辑
如何在 React Native 中映射 URL 路径和查询参数，以便打开正确的页面。
阅读完本指南后，你将了解这些部件是如何协同工作的，为什么 Universal Links 常常无声失败，以及在出现问题时如何快速调试。
深度链接基础
在实现之前，先了解你将会接触的两种深度链接类型：自定义 URL Scheme 和 Universal/App Links。两者都可以在应用内部打开特定页面，但它们的行为差异很大，适用场景也不同。
自定义 URL Scheme
自定义 Scheme 的形式如下：
myapp://reset-password?token=123它们简单且适用于内部导航，但也有严重的局限性：
- 仅在已安装应用时有效。
- 没有后备方案（否则链接什么也不做）。
- 任何其他应用都可以注册相同的 Scheme。
- 某些应用和邮件客户端会完全阻止它们。
自定义 Scheme 仍然适用于某些应用内部流程，但在外部发送的场景中并不可靠。
Universal Links（iOS）和 App Links（Android）
这是现代的做法。两个平台都转向基于 HTTPS + 域名验证 的安全深度链接。
Universal/App Link 看起来像普通链接：
https://example.com/reset-password?token=123- 若已安装应用，则打开对应页面。
- 若未安装，则回退到网站。
因为系统会验证你的应用“拥有”该域名，这类链接具有：
- 更高的安全性
- 更可预测的行为
- 在邮件、短信、浏览器以及大多数应用中均受支持
- 旨在防止劫持或错误的应用打开链接
何时使用哪种方式
- 使用 Universal/App Links 处理所有来自应用外部的场景（邮件验证、邀请、密码重置、分享链接、通知等）。
- 使用自定义 URL Scheme 进行应用内部的深度导航（尤其是在 WebView 与混合页面之间切换时）。
Universal & App Links 的工作原理
为了让 Universal Links（iOS）和 App Links（Android）可靠运行，了解用户点击链接时实际发生的过程非常重要。操作系统并不是直接“打开你的应用”。它会在决定链接是否可信之前执行一系列检查。这是大多数开发者看不到的部分，也是 Universal Links 常常无解释失效的原因。
操作系统的决策流程
域名验证
Universal/App Links 完全依赖域名验证。如果操作系统无法获取你的验证文件，或文件的响应不符合要求，Universal Links 将永远无法打开你的应用，无论移动端代码多么完美。
验证失败的常见原因：
- 验证文件被重定向
- 错误的 Content‑Type 头（例如
text/html而非application/json） - 托管平台将路由重写为
index.html - 域名错误（如
www.example.com而非example.com）
一旦操作系统验证失败，它通常会缓存该失败，这也是在测试时有时需要卸载应用的原因。
应用已安装 vs 未安装
验证通过后，操作系统会在两种结果之间做出选择：
如果应用已存在，链接会打开应用；否则，链接会打开网页。这是相较于自定义 URL Scheme 的一大优势：用户始终会落到一个有意义的页面。
实际场景
Universal/App Links 最常用于以下情形：
- 邮件验证
- 密码重置
- 邀请流程
- 内容分享
- 深度链接的通知
- WebView → 应用的交接
所有这些流程都依赖相同的操作系统决策逻辑，因此一次域名配置错误可能会一次性导致全部失效。
Web 端设置
Universal Links 和 App Links 只有在域名配置正确时才会生效。这是整个流程中最敏感、最容易出错的环节。如果 iOS 或 Android 读取不到符合格式和头信息的验证文件，即使其他一切都已就绪，链接也永远不会打开应用。
验证文件
两个平台都要求在非常特定的路径下放置文件。
iOS – apple-app-site-association
/.well-known/apple-app-site-association- 必须是 原始 JSON（不能带
.json扩展名） - 必须使用
Content-Type: application/json响应 - 必须返回 HTTP 200 状态码
Android – assetlinks.json
/.well-known/assetlinks.json- 必须是 有效的 JSON 数组
- 必须包含 包名 和 SHA‑256 证书指纹
- 必须使用
Content-Type: application/json并返回 HTTP 200
这些文件告诉操作系统：“该域名属于此应用，安全地直接打开链接”。如果操作系统无法加载或解析它们，Universal/App Links 将悄然失效。
文件托管要求
操作系统要求满足以下全部条件：
- 仅 HTTPS（不支持 HTTP）
- 无重定向（即使是一次 301 或 302 也会导致验证失败）
- 不需要身份验证或 Cookie 来获取文件
- 精确路径：
/.well-known/必须保持原样 - 正确的 Content‑Type 头 (
application/json) - 200 状态码响应
- 没有
index.html回退（Next.js 等框架常见问题）
如果你的托管平台会重写 URL 或强制返回 HTML，操作系统将拒绝你的域名。
服务器约束与检查清单
快速检查清单，确保域名设置正确：
- 两个文件均位于
/.well-known/目录下 - 通过有效的 TLS 证书使用 HTTPS 提供服务
- 无重定向（直接返回 200）
- 正确的
Content-Type: application/json头 - 文件内容为有效 JSON（iOS 为原始 JSON，Android 为数组）
- Android 文件包含正确的包名和 SHA‑256 指纹
- 不需要身份验证、Cookie 或其他请求修饰符
- 没有回退到
index.html或其他重写规则
只要满足上述清单，操作系统就能验证你的域名，Universal/App Links 将在各平台上可靠工作。