题干与适用场景
产品想把少量加密配置绑定到用户的 WebAuthn 凭据中，以减少服务端状态。请说明 largeBlob 的适用场景、注册与认证阶段的读写差异、客户端如何判断结果，以及不支持时怎样保持登录和数据正确性。
面试官考察点
- 是否理解 largeBlob 是与单个凭据关联的 opaque 数据，不是通用客户端存储。
- 是否区分注册时的
support、认证时的read/write，以及对应输出字段。 - 是否注意 FIDO/认证器容量、可发现凭据和一次只允许一个凭据写入等限制。
- 是否能设计能力探测、服务端备份、隐私和失败降级。
回答前需要澄清的问题
- 数据是否必须跟着凭据走，还是服务端数据库、IndexedDB 已足够？
- 数据大小、机密性、可恢复性和跨设备同步要求是什么？
- 目标认证器是否支持 largeBlob，是否使用可发现凭据？
- 写入失败、凭据丢失或用户换设备后，系统如何恢复？
30 秒回答框架
我会把 largeBlob 当作特定认证器能力，而非主存储。注册时请求 support: preferred 并读取 supported；认证时用 read 或 write，写入要精确指定一个凭据，结果通过 blob 或 written 判断。数据应加密、限量并保留服务端可恢复副本。能力缺失、容量不足或写入失败时继续使用服务端状态，不阻塞登录，也不把未确认写入当成成功。
分步骤深入解答
1. 选择正确的数据边界
规范把 largeBlob 定义为与凭据关联的 opaque 数据。它适合少量、与该凭据绑定的配置或密钥材料，不适合替代用户资料、跨凭据同步或大对象数据库。认证器容量有限，服务端仍应保存恢复所需的信息。
2. 注册阶段只探测能力
注册扩展使用 largeBlob: { support: "preferred" } 或 required。supported 只表示创建出的凭据是否支持存储；注册阶段不能直接写入 blob。若使用 required，不支持的认证器应被排除，产品需评估这是否会降低登录覆盖率。
3. 认证阶段读写要分开
认证时可请求 read: true 读取，或提供 write 写入；两者同时出现会失败。写入要求 allowCredentials 恰好包含一个凭据，成功后检查 written。读取成功才有 blob，不能只看扩展对象存在。
4. 设计隐私、恢复与降级
认证器上的数据是 opaque，不等于应用层加密；客户端和服务端应自行做加密、版本和完整性校验。凭据不可用、设备不支持、容量不足或用户拒绝时，回退服务端副本。日志只记录能力与结果，不记录 blob 内容。
高质量示范回答
我不会把 largeBlob 当成服务端状态的替代品。它适合把少量、不可解释的数据与某个 WebAuthn 凭据绑定。注册时用 support: preferred 做能力探测，读取 supported；认证时选择 read 或 write，写入必须只针对一个凭据，并检查 blob 或 written。应用层负责加密、版本和完整性，服务端保留可恢复副本。对不支持的认证器、可发现凭据限制、容量不足、写入失败和换设备，都回到服务端状态且不阻塞认证。只有在明确接受兼容性损失并有迁移方案时，才考虑 required。这样利用了认证器存储，同时保持登录和数据恢复的可靠性。
常见错误
- 把 largeBlob 当成 IndexedDB、Cookie 或任意大小的云同步存储。
- 误以为注册阶段可以直接写入 blob。
- 同时发送
read和write，或写入时指定多个凭据。 - 只判断扩展对象存在，没有检查
supported、blob或written。 - 未加密就把敏感资料写进 opaque blob。
- 认证器不支持时阻断登录，而没有服务端回退。
追问及应对
preferred 与 required 如何选择？
preferred 允许继续选择不支持的认证器并走降级；required 会排除不支持的候选认证器。除非产品能接受覆盖率下降且必须依赖该能力，否则优先 preferred。
为什么写入必须只有一个凭据？
规范要求写入操作通过唯一的 allowCredentials 目标定位要更新的凭据。多个候选会导致不支持错误，应用应先确定用户选择的凭据。
设备迁移时怎么处理？
把 blob 视为可选缓存或密钥副本，服务端保存恢复材料。新设备用重新注册或认证流程取得服务端状态，不能假设认证器上的 blob 会自动跨设备同步。