---
url: 'https://www.corbado.com/zh/passkey-benchmark-2026/conditional-ui-usage'
title: 'Conditional UI 登录完成率基准测试'
description: 'Conditional UI 登录基准测试，展示通行密钥建议如何影响桌面端登录完成率。'
lang: 'zh'
dir: 'ltr'
keywords: 'Conditional UI, 通行密钥自动填充, 条件中介, 通行密钥登录完成率'
---

# Conditional UI 登录完成度

*由英语自动翻译。查看[原文](https://www.corbado.com/passkey-benchmark-2026/conditional-ui-usage.md) →*

[← 所有基准测试](https://www.corbado.com/zh/passkey-benchmark-2026.md)

Conditional UI 登录完成度比较了用户键入标识符时与提供字段级通行密钥帮助时的服务器前登录路径。它显示了为什么服务器端通行密钥成功率看起来近乎完美，而真实的 Conditional UI 性能取决于字段配置、用户选择、最终登录完成度和速度。

## Conditional UI 实际中断的位置：三个测量点

*Q1 2026 · 三个测量点的 Conditional UI*

Conditional UI (CUI) 通常被报告为一个数字：服务端成功率。该数字处于流程的最末端，看起来近乎完美。而用户实际流失的两个更早阶段的数字如下。

1. **首次建议交互** — *55–90%*. 用户选择并完成第一个可见的通行密钥建议. 这是到达服务端之前的时刻：建议可见，用户选择它，浏览器验证完成。此处的流失意味着用户关闭了提示、切换账号、无法在本地解锁、设备上没有可用的凭据，或者在生成签名请求前放弃。
2. **最终的 CUI 路径登录** — *90–95%*. 包含重试和回退后的最终登录成功率. 登录最终成功，有时是在再次尝试 CUI、自动填充或手动输入回退之后。这是面向用户的完成率数据。
3. **多数团队报告的指标** — *97–99%*. 提交签名请求后服务端验证成功. 此数字对评估服务端可靠性很有用，但它的起点是在 Conditional UI 用户体验已经成功之后。

### 主要对比：手动与辅助输入

| 浏览器 | 手动完整 | 辅助完整 | 辅助 Δ | 手动重试 5m | 辅助重试 5m |
| --- | --- | --- | --- | --- | --- |
| macOS Chrome | 86% | 91% | +4pp | 25% | 32% |
| macOS Safari | 83% | 91% | +9pp | 23% | 23% |
| Windows Chrome | 87% | 89% | +2pp | 22% | 24% |
| Windows Edge | 86% | 88% | +2pp | 21% | 21% |

### 辅助输入细分

| 浏览器 | 辅助内的 CUI 占比 | CUI 完整完成 | 受保护自动填充 | 未受保护自动填充 |
| --- | --- | --- | --- | --- |
| macOS Chrome | 28% | 94% | 91% | 89% |
| macOS Safari | 49% | 94% | 87% | 89% |
| Windows Chrome | 11% | 94% | 86% | 89% |
| Windows Edge | 9% | 94% | 86% | 88% |

### Conditional UI 转化为采用率的关键

决定性的数字不是浏览器是否支持 Conditional UI。而是真实用户在合适时机看到正确的通行密钥建议，然后在没有账号混淆、密码管理器绕路或手动回退的情况下完成登录的频率。

使用这些信号来解读你自己的部署情况。

- **建议展示率低** (资格缺口): 检查是否缺乏凭据覆盖、通行密钥在其他设备上、字段绑定错误、密码管理器覆盖、RP/账号上下文不匹配，或者由于刚推出尚未建立足够的凭据基础。
- **间接完成** (路由缺口): 用户依然能登录，但不是直接登录。优化目标是速度和直接性：减少标识符绕路，支持恢复，并在上下文足够强的情况下使用受信任设备或一键登录入口。

### 备注

1. 最终登录完成率汇总了同一登录流程中的后续交互：在最终登录完成之前，用户可以切换账号、关闭提示、重试 CUI 或回退到手动输入。
2. 有效的 Conditional UI 断言几乎总是被服务端接受；测量缺口出现在断言生成之前。因此，仅基于服务端的报告看起来比真实的登录输入体验更好。
3. 辅助输入中的 Conditional UI 占比取决于部署的设备组合以及产品上线的时间。Windows 桌面端部署通常显示较小的本地建议基数，因为许多用户的可用通行密钥保存在手机上，而非当前设备。
4. 健康的自动填充行为是健康的 Conditional Create 的先决条件。请参阅 [Conditional Create Rate](/zh/passkey-benchmark-2026/conditional-create.md) 了解反向视图，其中自动填充质量预示了在密码登录成功后通行密钥被自动创建的频率。

## 延伸阅读

Corbado 精选研究与主要参考资料。

- **实施 · web.dev** — [Sign in with a passkey through form autofill](https://web.dev/articles/passkey-form-autofill) — Google 在现有用户名和密码表单中实施 Conditional UI 的指南。
- **Conditional UI · Corbado blog** — [WebAuthn Conditional UI Passkeys & Autofill](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill) — 关于通行密钥自动填充、条件中介和标识符字段配置的实用说明。
- **设备支持 · passkeys.dev** — [Passkey Device Support](https://passkeys.dev/device-support/) — 跨平台和浏览器的通行密钥自动填充和登录行为的兼容性矩阵。

[← 所有基准测试](https://www.corbado.com/zh/passkey-benchmark-2026.md)

---

*由面向 CIAM 团队的通行密钥情报平台 Corbado 发布的关于通行密钥准备度、创建、使用及采用策略的年度基准报告。[了解更多 →](https://www.corbado.com)。*