Web平台不存在Get Installed Related Apps API；该API从未成为标准，Chrome中已废弃移除，当前仅能通过深度链接启发式推断应用安装状态。
Get Installed Related Apps API 本身并不存在——这是个常见误解。目前（截至2026年4月）Web 平台**没有名为 Get Installed Related Apps 的标准 API**，W3C、WHATWG 或 Chromium/WebKit/Gecko 官方规范中均无此接口。你可能混淆了以下几类真实能力：
实际可用的关联应用探测机制
浏览器真正支持的、用于判断原生应用是否安装的机制只有两种，且均有严格限制：
-
Android App Links 验证结果：通过
navigator.getInstalledRelatedApps()（已废弃）或更现代的getInstalledRelatedApps()（需配合数字资产链接验证）——但该方法仅在 Android 上部分 Chrome 版本中短暂实验性支持，已于 Chrome 120+ 彻底移除，且从未进入标准。 -
Intent URL scheme fallback 检测：利用自定义 scheme（如
myapp://open）尝试跳转，配合beforeunload或定时器判断是否成功唤起。这是当前最广泛使用的间接探测方式，但不返回“已安装”布尔值，只能推测，且 iOS Safari 完全屏蔽 scheme 调用。
为什么不能直接读取原生应用安装状态
出于隐私与安全设计原则，现代浏览器明确禁止网页获取设备上已安装应用列表。这属于操作系统级敏感信息，任何 Web API 若能直接返回 ["com.example.app", "jp.co.game"] 类似结果，将构成严重权限越界。因此：
- 所有“探测已安装”的方案本质上都是启发式行为推断，非真实状态读取；
- Chrome 曾提供的
getInstalledRelatedApps()也要求网站提前在https://example.com/.well-known/assetlinks.json中完成双向绑定验证，且仅返回经声明的关联包名，而非全量列表； - 该 API 在 2023 年底被标记为废弃，2024 年起主流版本不再启用，2026 年已完全不可用。
可行的 DOM 交互异步调整策略
若目标是“根据原生应用可用性动态更新页面行为”，可采用稳健的 fallback 流程：
-
优先尝试深度链接唤起：用
window.location.href = "myapp://home"触发跳转； -
设置 250ms 定时器监听页面可见性：若唤起后页面未失焦（
document.hidden === false），说明唤起失败，大概率未安装； - 立即显示降级 UI：例如将“打开 App”按钮切换为“下载 App”链接，同时预加载对应 Store 页面；
- 避免阻塞主流程：所有检测逻辑必须异步执行，不依赖 Promise resolve，因唤起无回调事件；
-
补充 PWA 安装横幅检测：用
beforeinstallprompt事件判断用户是否已添加 PWA，作为轻量替代路径。
替代建议：转向可信通道协同
更可靠的方式是放弃前端单方面探测，改用服务端或混合方案：
- 用户首次访问时，客户端 SDK（Android/iOS App）向业务后端上报设备标识与安装状态；
- 网页通过登录态或 Device ID 向后端查询该设备是否已安装对应原生应用；
- 返回结构化响应（如
{"installed": true, "version": "3.2.1"}），前端据此精准更新 DOM 和交互逻辑； - 该方式绕过浏览器限制，支持灰度控制、AB 测试及埋点归因，已在电商、金融类 App 落地验证。
