apple-app-site-association（简称 AASA）是一个存放在你 Web 服务器上的 JSON 格式的配置文件。它的核心作用是在你的 Web 域名与你的 iOS App 之间建立一种“强信任的数字安全连接”。
通过这个文件，你可以向 Apple 证明：“这个域名确实属于这个 App 的开发者，我授权这个 App 直接打开这个域名下的特定 URL。”
AASA 的工作原理
AASA 的工作流程可以分为：配置、抓取、匹配三个阶段。
- 配置与部署 (Server Side)
开发者将包含 App ID (Team ID + Bundle ID) 的 AASA 文件上传到服务器的 .well-known/ 目录下。
注意： 该文件必须通过 HTTPS 访问，且不能有任何后缀名（不能是 .json）。
- 系统抓取 (Client Side - Install Time)
当用户从 App Store 安装 App，或者系统检测到 App 更新时，iOS 会自动检查该 App 内部配置的 Associated Domains。
如果发现配置了 applinks:example.com，iOS 会去访问 https://example.com/.well-known/apple-app-site-association 并下载它。
Apple CDN 缓存： 为了减轻服务器压力，iOS 通常会从 Apple 的 CDN 节点下载该文件，而不是直接请求你的服务器。这意味着你修改文件后，通常需要几个小时甚至更久才能在真机上生效。
- 拦截与跳转 (Runtime)
当用户点击一个指向该域名的链接（例如在短信、微信或网页中点击 https://example.com/deco）时：
iOS 系统会查看已下载到本地的 AASA 规则。
如果 URL 路径符合 AASA 中的 paths 或 components 定义，系统会直接拉起对应的 App。
如果没有安装 App，则会在 Safari 中打开该网页。
AASA 能做啥？（核心功能）
目前 AASA 文件主要负责以下三大功能：
- Universal Links (通用链接)
功能： 让 URL 链接直接跳转到 App 内部特定页面，而不是在浏览器打开。
优势： 相比传统的 Schema (myapp://) 跳转，Universal Links 更安全（无法被其他 App 劫持），且如果没安装 App，它能平滑降级到网页，体验极佳。
- App Clips (应用切片)
功能： 让用户通过扫描二维码、NFC 或点击链接，在不安装完整 App 的情况下启动一个轻量级的微型 App。
实现： 必须在 AASA 中配置 appclips 部分，系统才能识别哪些 URL 对应哪些 App Clip 体验。
- Shared Web Credentials (共享网页凭据)
功能： 允许 App 共享存储在 Safari 中的用户账号密码。
体验： 用户在网页版登录过，下载 App 后，系统可以自动填充账号密码，实现无缝登录。
AASA 文件结构解析 (Objective-C 开发视角)
由于你正在进行 OC 环境下的开发，理解这个文件的结构对你处理逻辑至关重要：
JSON
{
"applinks": {
"details": [
{
"appIDs": [ "TEAMID.com.tplink.aria" ],
"components": [
{ "/": "/deco/*" }
]
}
]
},
"appclips": {
"apps": [ "TEAMID.com.tplink.aria.Clip" ]
}
}
appIDs/apps: 决定了哪个“身份证”的 App 有权打开链接。
components/paths: 决定了哪些“路径”会被拦截。例如配置了 /deco/*，那么 https://domain.com/deco/123 会跳转，而 https://domain.com/other 则不会。
下一步建议
由于 Apple 的 CDN 缓存非常顽固，如果你刚刚修改了服务器上的文件但发现 App Clip 还是没反应：
检查 CDN 状态： 访问 https://app-site-association.cdn-apple.com/a/v1/yourdomain.com 看看 Apple 缓存的到底是不是你的最新版本。
强制刷新： 在测试机上卸载重装 App，或者重启手机，强制触发系统重新抓取。
