07
Passkey 验证 · get() 与"自动建议"
两条路径：按钮触发（弹窗选择器）与 conditional（出现在密码管理器建议里，点一下就登录）。
webauthnget()conditional
autocomplete=username
current-password
同一个 form 里既有密码字段又支持 passkey 时，Chrome 会把两者合并进一个建议列表——这是最容易看出管理器实现差异的地方。
FIXTURE · 与 06 页同一个账号
username = pm06@example.com
ALLOWCREDENTIALS
留空才能测出"这台设备的 passkey 列表"；限定时若 id 不匹配会直接失败
USER VERIFICATION
DISCOURAGED 下若仍弹生物识别，说明该实现拒绝无 UV 登录
MEDIATION
SILENT = 不弹 UI，没有可用凭据立即失败；CONDITIONAL = 进入密码建议下拉
TIMEOUT(S)
RESULT · get() 返回值解剖—
尚未调用 get()。
CONDITIONAL 状态IDLE
CONDITIONAL 模式下浏览器不会弹框：passkey 会出现在用户名输入框的密码管理器建议下拉里，选中即完成 get()。启动后请点上面那个输入框。
本机登记簿来自 06 页
KNOWN FAILURE MODES
- CONDITIONAL 需要安全上下文 + 可发现凭据（residentKey=required 建的那批）。用 discouraged 建的 key 不会出现在建议里。
- SILENT 在没有凭据时立刻 NotAllowedError，这正是"无 UI 静默登录"的判定方式。
- 限定 allowCredentials 却选了别的设备建的 id ⇒ NotAllowedError，容易被误读成"passkey 坏了"。
- 没有后端：challenge 由本页生成、由本页比对。签名与 counter 未做服务端校验，counter 回退（克隆密钥检测）只能人工看趋势。
- 反复点 GET 会累积多条同源凭据；某些管理器的建议列表会开始重复显示，这是它的去重策略问题，不是本站的。