App深度链接打不开、Universal Links排查、Android App Links验证失败时，先识别链接机制、安装状态与调用环境，再分查AASA、Associated Domains、assetlinks、签名及ADB状态。
那天，测试群里贴来两张截图。
同一个HTTPS地址，iPhone已安装App却进了浏览器，Android测试机则去了商店。产品负责人盯着域名关联文件，客户端同事怀疑系统缓存，投放同事却说链接平台后台一切正常。假设这是一次运行期事故，最先要做的不是改配置，而是把截图还原成可复核的观察记录。
先讲个场景：遇到App深度链接打不开、Universal Links排查、Android App Links验证失败，先登记机制、入口、安装状态、调用环境与实际落点。商店可来自外层路由，不能直接写成两种原生机制的共同回退。
先把“已安装仍进浏览器”写成证据
负责人把两张截图拆成几行：原始URL是什么，从系统浏览器、内嵌容器还是投放位点入；设备当时是否已安装目标App；最终停在网页、商店还是App内页面。此时还不判断AASA不生效，也不判断autoVerify失败。
面对“App深度链接打不开、Universal Links排查、Android App Links验证失败”这组现象，建议先完成以下登记：
认机制：确认眼前是标准Universal Links、Android App Links，还是外层Scheme、Deferred或归因链接。机制未明时，后续证据列保持空白，避免拿错平台规则解释落点。
认入口：保存原始HTTPS地址、实际点击位置、跳转过程和最终URL。若中间出现重定向，只记录观察到的链路，不凭终点补写中间过程。
认状态：登记App安装状态、客户端构建来源、签名条件、系统与容器环境。不同构建不能混成同一次复测。
认落点：把浏览器、网页、应用商店、App首页或App内目标页分开写。相同“没打开目标页”，责任层并不相同。
这些动作只在自有或授权域名、App、设备与日志内进行。业界存在多种路由做法；缺少原始URL或环境记录时，结论先停在“观察不足”，而不是把责任推给关联文件。
别在商店落点纠结，战场在链接机制
常见误区是：未安装App，原生深链就应当去商店。换个维度看，Apple支持的未安装语义是由默认浏览器打开URL；商店、Deferred、Scheme或归因fallback属于需要另查的外层路由候选。Android侧也要先辨认标准App Links与外层机制，不能沿用一条“未安装就进商店”的统一链。
落点像结果，机制才是入口。
HTTPS入口 ├─ 标准原生关联 │ ├─ 已安装 → 平台证据分叉 │ └─ 未安装 → Web语义 └─ 外层路由候选 └─ 商店／Deferred／Scheme／归因
图里故意没有把Apple与Android画进同一条验证链。先做机制分诊，再分别取证；若地址经过外层服务，商店落点只能说明这条路径值得核对，尚不足以证明原生关联成功或失败。
这一步还有一个容易跑偏的问题：落点异常会不会说明多端架构选错了？不会仅凭一次症状得出这种结论。读者刚分清机制后，下一问应当回到能力范围，而不是借故障重做架构讨论。
共同责任层相同，平台证据不要合并
故事走到这里出现了反转：截图中的两个终点虽然相似，所缺的并不是同一份文件。共同责任层可以统一命名，字段却要分列保管。
机制与入口层：保存原始URL、调用来源、中间跳转与外层路由配置归属。缺失后果是把归因服务的fallback误认成系统默认行为。
网站关联层：Apple侧看AASA对应关系；Android侧看每个主机的assetlinks.json验证材料。这里只统一责任类别，不互换文件或字段。
App声明层：Apple侧核对Associated Domains与entitlement；Android侧核对intent filter及autoVerify。构建包与声明材料要能对应。
平台验证层：Apple关注安装时关联验证及当前文档所述条件；Android关注安装或手动验证后的状态。验证时间、环境与结果应留档。
URL匹配层：逐项对照主机、路径和App接收条件；重定向前后的地址分别保存。只看最终页面会丢掉匹配入口。
环境与用户层：记录浏览器、WebView、投放位、用户选择、系统环境与构建来源。这里允许保留未知，不把单台设备经验外推。
若入口来自推送通知，产品负责人还要把“通知是否送到”与“点击后如何路由”分成两份记录。前者不是本篇任务，后者才进入这里的机制分诊。
完成共同层登记后，再分派责任：域名持有人提供网站关联材料，客户端负责人提供App声明与构建信息，授权设备持有人记录真机状态，投放或归因负责人说明外层路由。若其中一方拿不到材料，就把“材料不可得”列为证据缺口，不让另一平台的结果代填。
Apple分支：AASA不生效时，先查安装验证链
iOS测试负责人接过同一份记录，核对顺序应从App声明与域名关系开始，而不是先反复点击链接。
核对目标构建中的Associated Domains及对应entitlement，确认它们与本次测试域名、App和构建来源相符；不相符时，先停止引用该次落点作验证结论。
检查AASA与当前URL匹配材料，保留原始访问结果和变更记录；若涉及Apple CDN条件，按当前Apple文档与真机结果核查，不填写固定刷新时点。
重新梳理安装动作。系统在安装App时尝试下载关联域文件，并验证entitlement中的域；因此要记录安装时使用的构建与当时可得证据。
核对App是否接收并处理了目标URL。系统已把入口交给App，与App内是否进入预期页面，是相邻但不同的责任层。
Apple FAQ｜Universal Links为什么打开Safari
Universal Links为什么打开Safari，先看什么新条件？ 先看点击是否发生在与目标网页关系特殊的Safari场景，并把来源页与目标域记录下来；Safari同域细节应按当前文档及真机观察处理。这个视角不同于AASA文件可访问性，不能用一次Safari落点替代安装验证证据。
未安装为什么没有进入应用商店？ 先确认团队是否另行配置了商店、Deferred或归因路由。标准语义下，未安装时URL在默认浏览器打开；没有外层路由材料，网页落点并不异常，也不应临时编造商店规则补齐预期。
走完这条分支，AASA不生效仍可能只是一种现象描述。可交接材料应包括域名、AASA观察、Associated Domains与entitlement对应关系、安装时构建、原始URL、调用环境、App接收情况，以及尚未解释的Safari或CDN条件。浏览器环境与缓存细节只按当次记录解释。
Android分支：assetlinks.json验证与ADB状态要对上构建
Android负责人面对的是另一套证据。即使iOS已恢复，也不能据此跳过DAL、签名和设备状态核对。安装会触发系统自动验证；授权设备上的当前状态，才是这台设备此构建的排查材料。
逐个核对本次URL涉及的主机，检查对应assetlinks材料中的包名与SHA-256是否和当前分发构建匹配。测试签名、正式分发签名或其他来源的构建应分别记录。
检查intent filter覆盖的scheme、host及路径条件，并确认autoVerify声明属于当前包。若URL经过重定向，把重定向前后的主机都放回机制层审视。
在授权设备上依据当前Android规则执行安装触发或手动验证，再用
pm get-app-links查看当前状态。命令输出与包版本、签名、设备环境一起保存，不能只截一行状态。检查用户关联与实际调用环境。系统浏览器、WebView、投放位以及用户历史选择会改变观察结果；OEM、无Google服务设备、动态规则版本和缓存行为分别留档。
Android FAQ｜App Links为什么已安装仍进浏览器
App Links为什么已安装仍进浏览器，还有什么常被漏掉？ 除了autoVerify失败，还要对照当前分发签名。assetlinks.json验证材料与另一个构建匹配时，网页文件看似完整，当前安装包仍缺少对应证据；因此包来源和SHA-256必须同状态记录放在一起。
什么情况下应该用ADB查看App Links状态？ 当目标是解释授权测试设备上的当前关联状态，并且包名、构建来源与测试URL已经登记时，ADB结果才有上下文。它不能替代其他设备、OEM或内嵌容器的真机观察，也不能把用户选择自动改写成网站配置故障。
Android App Links验证失败的交接材料，应覆盖intent filter、autoVerify、各主机assetlinks、包名、SHA-256、安装或手动验证动作、pm get-app-links状态、用户关联及调用环境。若命令不可用或设备条件不同，就把边界写进记录，不套用另一台设备的结论。
从观察值收口：跨平台证据速查表
回到测试群，产品负责人终于不再问“该改哪一份配置”，而是问“这一行观察值缺哪份证据”。处理App深度链接打不开、Universal Links排查、Android App Links验证失败，下面这张表只用于分诊，不是平台官方评级。
| 观察值与维度 | 判断依据 | Apple证据 | Android证据 | 外层路由候选 | 不可外推边界 | 下一证据 | 残余未知／无法定位出口 |
|---|---|---|---|---|---|---|---|
| 已安装，从系统浏览器进网页 | 原始HTTPS未进入App，且构建、入口与落点均有记录 | AASA、Associated Domains、entitlement、安装验证、URL匹配、App接收 | intent filter、autoVerify、assetlinks、包名、SHA-256、ADB状态 | 检查点击前是否经过归因或跳转服务 | 单次结果不覆盖其他浏览器、设备或构建 | 分平台补齐声明与验证状态 | 材料齐全仍不一致时，连同环境记录交给对应平台或容器责任方 |
| 未安装，落到网页 | 安装状态已确认，最终URL仍是原始Web目标 | 对照默认浏览器语义 | 保留当前设备与浏览器观察 | 查是否原本配置商店、Deferred或归因fallback | 网页落点不说明外层商店路由存在 | 向路由持有人索取配置与跳转记录 | 无外层材料时，停止推断商店责任层 |
| 已安装，落到应用商店 | 跳转过程中出现商店地址或外层服务痕迹 | 原生关联证据与外层链路分开 | 系统验证状态与外层链路分开 | 重点核对归因、Scheme或Deferred候选 | 商店终点不证明原生机制共同回退 | 保存完整跳转过程与最终URL | 中间链路不可见时，交由外层路由持有人说明 |
| WebView或投放位结果不一致 | 系统浏览器与内嵌环境复测结果不同 | 记录容器、系统与Safari观察 | 记录容器、OEM与用户关联 | 查投放位重写及归因规则 | 不把内嵌容器经验扩展到其他环境 | 用同一URL分环境真机复测 | 容器规则不可得时，保留环境未知 |
| 更换分发构建后才异常 | 域名未变，构建来源或签名条件发生变化 | 对照新构建entitlement与安装验证 | 对照包名、SHA-256及设备状态 | 排除外层链接版本变化 | 一个构建的结论不覆盖另一构建 | 建立构建—签名—验证记录 | 签名材料无权限时，升级给构建持有人 |
| Validator显示正常但真机异常 | 工具只覆盖部分网站材料，设备结果相反 | 回到安装、App声明与接收证据 | 回到系统验证、用户关联与环境 | 检查工具未覆盖的外层链路 | Validator不能替代系统验证 | 附工具结果但以授权真机取证继续 | 证据仍断裂时，提交原始URL、构建、签名、环境和复测记录 |
工具给线索，责任要靠证据闭环。
这张表也揭开了行业里最费时间的一幕：内嵌浏览器改写入口，分发签名又换了构建，外层归因路由还把失败路径送往商店。团队若只盯一份关联文件，会反复改配置；只看Validator的绿灯，又容易误购工具。采购或承诺修复前，应先确认工具究竟覆盖网站文件、系统验证、容器行为还是外层路由。
时效上，按当前平台规则、版本和真机结果复核；风险上，只处理授权资产；长期上，保存版本、签名、环境与复测记录；资金上，不凭单一工具结果或单次落点做采购决定。无法定位时，升级材料至少包含原始URL、机制判断、安装状态、构建与签名条件、平台证据、调用环境、跳转记录和残余未知。
真机复测后，把维护职责写进交接单
离开测试群前，再按系统浏览器、WebView、投放位分别复测已安装与未安装状态；每次保存原始URL、构建来源、签名条件、环境、实际落点和复测结果。Apple与Android各自归档，外层路由另列，旧结果不覆盖新版本记录。整个过程限定在授权设备、域名、App与日志中。
一次故障收口后，团队自然会追问：这些证据以后由谁持续维护？
若你正在评估App维护能力与多端交付边界，可通过WG官方商务入口沟通多端交付及维护职责。联系WG前，可先完成一次职责对照，重点整理：机制与入口归属、Apple和Android各自的证据持有人、构建签名及版本记录负责人、真机复测与外层路由交接人。沟通用于厘清交付和维护边界，不预设专项修复结果，也不承诺不同环境获得一致落点。