用户点"打开App"没反应，很多时候不是代码坏了，而是这次唤起被"环境"拦下来了——系统、微信、信息流客户端、浏览器各有各的规则。排查的第一步不是改代码，而是先定位"是哪一层拦的"。
一、先定位：问题出在哪一层
用户点"打开App"没反应，先问三个问题，30秒缩小范围：
-
只在某个App或浏览器里打不开？→ 环境的问题；
-
只在没装App时不行？→ 承接的问题，链路本身没毛病；
-
自动弹出不行、用户自己点行？→ 触发的问题，缺用户手势。
答不上来，就按三层逐层查：
第一层·平台和媒体的"确认关"：App要拉起另一个App时，系统会弹确认窗；媒体客户端还会加自己的确认和限流：第一次要确认、点多了被限制。这关的核心是用户授权——别想着绕过，把按钮文案写清楚"将打开XX App、进入XX页"，让唤起发生在真实点击之后，通过率反而高。
第二层·链接是否被信任：媒体可以按"钥匙类型"拦截：允许验证型链接，却限制某些自定义暗号。验证型链接还要"验明正身"——身份证明文件配错、证书不匹配、子域名漏配，都会被降级成网页。查的时候分开查：自定义暗号不行，查注册、冲突和媒体允不允许；验证型链接不行，查身份文件（AASA/assetlinks.json）和域名配置；短链不行，查跳转后最终域名有没有变。
第三层·触发方式与用户行为：浏览器更信任真实点击；页面自动弹的、脚本模拟点击的，缺明确意图，更容易被拦。还有一类容易被误判成Bug的行为：用户在Safari里本来就在浏览这个网站，再点同域名的唤起链接，系统会尊重他"继续看网页"的意图、留在网页里——这不是配置错误，是系统设计。
二、真实案例与排查验证
三个案例，把上面的排查方法走一遍：
微信里点广告没反应：微信内唤端成功率长期低于30%，按环境拆分发现微信内几乎为0、系统浏览器正常。根因：微信内置浏览器对唤起限制严格。方案：微信内引导"浏览器打开"＋复制口令兜底。遇到"打不开"，先查这个场景。
信息流App改版后成功率骤降：一周内从68%跌到41%，没发版、没改配置，只有某个信息流App里的自动唤起全挂、手动点击正常。根因：媒体升级后新增了"必须用户手势"的要求。方案：自动唤起改成用户点击触发、限制频次。
Safari里点了同域名链接却留在网页：身份文件、域名配置都正常，手动输入网址却能打开。根因：系统尊重"用户正在浏览网页"的意图，是正常行为。方案：不在这类场景硬唤起，用站内提示引导。
"我的手机上能打开"证明不了稳定。测试至少覆盖：iOS/安卓主要版本，Safari、Chrome和厂商浏览器，微信和信息流内置浏览器，App已装/未装/刚升级，手动/自动，不同钥匙类型，不同网络。
| 系统与环境 | App状态 | 触发 | 使用的钥匙 | 预期结果 | 重点检查 |
|---|---|---|---|---|---|
| iOS・Safari | 已装 | 点击 | 验证型 | 打开目标页 | 身份文件、同域行为 |
| iOS・Safari | 未装 | 点击 | 验证型 | 留在H5承接 | H5与下载入口 |
| iOS・微信等内置浏览器 | 已装 | 点击 | 验证型/暗号 | 打开或弹确认 | 浏览器支持、弹窗 |
| 安卓・Chrome | 已装 | 点击 | 验证型 | 打开目标页 | 身份文件、签名 |
| 安卓・Chrome | 未装 | 点击 | 验证型/暗号 | H5或商店 | 跳转有效 |
| 安卓・厂商浏览器 | 已装 | 点击 | 验证型/暗号 | 打开或弹确认 | 厂商策略差异 |
排查漏斗拆成五级：点击→发起→App打开→到达目标页→业务动作，哪两级掉得最狠就查哪层。示例：点击100→发起80→App打开60→到达目标页55→业务转化10——最后一级断崖，问题在页面承接和业务链路，不在唤端。数分同学按"系统×环境×入口"拆分看，别只看整体；保留历史测试结果，便于对比App改版、系统升级或媒体策略变化。
三、稳定做法：兼容＋降级
- 正规入口默认用验证型链接；
- 明确支持的环境用自定义暗号补充；
- 让唤起发生在真实点击之后；
- 失败后继续给用户H5内容，没装App引导下载；
- 自动尝试限次数与间隔；
- 媒体规则变化后及时回归。
目标不是绕过平台的安全规则，而是让每一种失败都有合理承接。
结语
唤端拦截不是单一故障，而是一组环境策略的结果：平台保护用户授权、媒体管理安全与体验、浏览器要求真实交互、链接要验明正身。先问三个问题缩小范围，再逐层定位，最后用漏斗和环境矩阵验证，就能从"改代码碰运气"升级为可监测、可解释的唤端治理。