Web 通行密钥就绪度
Web 通行密钥就绪度衡量当前浏览器受众在技术上能够使用通行密钥的比例。它将技术限制与实施选择分开，以便采用工作从实际的上限开始。
2025年初与年末对比
各平台的 Web 通行密钥就绪度
就绪度是基于已完成的 Web 登录进行衡量的。我们不仅依赖于浏览器 API 的返回结果（getClientCapabilities / isUVPAA）。只有当浏览器 API 返回肯定结果，且实际已配置可用的平台身份验证器（例如已注册 Windows Hello，激活了 iCloud Keychain 或 Google Password Manager）时，该设备才被视为就绪。API 返回“是”但未配置任何通行密钥提供程序的设备不计算在内。
| 平台 | 2025 年初 | 2025 年末 |
|---|---|---|
| iOS1,2 | 100% | 99% |
| Android | 96% | 97% |
| ChromeOS | 94% | 95% |
| macOS | 88% | 91% |
| Windows 113 | 85% | 85% |
| Windows 103 | 56% | 70% |
Windows 浏览器划分
Chrome 在 2025 年期间提升强劲，Edge 在年末较弱但在 Q1 2026 展望中赶超，而 Firefox 从较低基数逐步改善。
| 浏览器 | 2025 年初 | 2025 年末 | Q1 2026 |
|---|---|---|---|
| Chrome | 75% | 87% | 88% |
| Edge | 71% | 68% | 85% |
| Firefox | 56% | 60% | 66% |
- 在此表格中，iOS 仅限浏览器。排除了 App 和 webview 上下文，因为对于信赖方通行密钥而言，它们并非正常的浏览器上下文；Google App 就是最重要的例子。根据市场构成的不同，这些上下文约占 iOS Web 使用量的 1-10%。由于通行密钥在这些环境中的工作方式与浏览器不同，这部分流量会将测得的 iOS 就绪度拉低约相同的幅度，并增加登录摩擦。
- iOS 26.2 WKWebView 的
isUVPAA()退化问题在 2025 年底已经显现，随后在接下来的几个月中进一步严重拉低了第三方 iOS 浏览器的就绪度，直至开始恢复。Corbado 在此 iOS 26.2 isUVPAA 分析中记录了该错误及恢复路径。 - Windows 10 和 Windows 11 表明微软在通行密钥就绪度方面的持续努力取得了成效，尤其是在 2025 年 12 月和 2026 年 2 月的更新潮前后，Windows 11 在 2026 年的进一步改善也清晰可见。浏览器占比差异也很重要：Google Password Manager 通行密钥同步于 2024 年 9 月 19 日登陆桌面端 Chrome，而微软于 2025 年 11 月 3 日宣布在 Windows 版 Edge 142 中实现通行密钥的保存和同步。这些提供程序的变更解释了为何 Chrome 在整个 2025 年都在改善，而 Edge 则在 2026 年初更明显地赶上。
相关资源
延伸阅读
Corbado 精选研究与主要参考资料。