webauthn注册报notsupportederror需确保https或localhost环境；challenge必须随机一次性防重放；attestation推荐"none"平衡隐私与兼容性；notallowederror是用户拒绝而非服务端错误。
WebAuthn注册时 navigator.credentials.create() 报错 “NotSupportedError” 怎么办
常见于开发环境未启用 HTTPS 或 localhost 以外的 HTTP 地址访问，浏览器直接拒绝调用 WebAuthn API。
必须确保：
- 本地开发用
http://localhost或http://127.0.0.1（Chrome/Firefox 允许，但 Safari 要求https://或明确加localhost） - 生产环境必须走
https://，哪怕自签名证书也行（但需用户手动信任） - 检查是否在非安全上下文（如 iframe 嵌入、
data:协议、file:协议）中调用 —— 这些场景下navigator.credentials为undefined
快速验证：打开控制台执行 !!navigator.credentials，返回 false 就说明环境不满足基础前提。
后端生成 challenge 为什么必须是随机且一次性？
WebAuthn 的 challenge 是防重放攻击的核心。它不是随便一个字符串，而是由服务端生成的、带时间戳和会话绑定的 base64url 编码随机字节（推荐 32 字节）。
常见错误包括：
- 用固定字符串（如
"abc123"）—— 攻击者截获一次响应就能无限重放 - 用时间戳或用户 ID 拼接生成 —— 可预测，失去随机性
- 未在 Redis/DB 中存储并校验（注册/登录流程结束后立即失效）
Node.js 示例（使用 crypto.randomBytes(32)）：
const challenge = crypto.randomBytes(32).toString('base64url');
注意：base64url 不是标准 base64（要替换 + → -、/ → _、去掉 =），否则前端传给 create() 会解析失败。
attestation: "none" 和 "direct" 在注册时怎么选？
这决定证书是否暴露设备厂商信息，直接影响隐私与兼容性平衡。
attestation: "none"（推荐开发/多数生产场景）：
- 浏览器不返回可信平台模块（TPM）或安全芯片证书，只返回公钥 + 签名
- 兼容性最好，iOS Safari、旧版 Edge 都支持
- 服务端只需验证签名有效性，无需证书链校验
attestation: "direct"（仅合规强要求场景）：
- 返回完整证书链，可溯源到特定认证器型号（如 YubiKey 5Ci）
- 部分 Android 设备、Windows Hello 默认不提供，会退化为
"none"或直接失败 - 后端需集成证书解析 + CA 校验逻辑，显著增加复杂度
除非客户明确要求设备级审计，否则默认用 "none" 更稳妥。
登录时 navigator.credentials.get() 返回 NotAllowedError
这不是网络或代码错误，而是用户主动拒绝授权（点“取消”）、认证器无响应、或系统策略拦截（如 macOS 触控 ID 被禁用）。
关键处理点：
- 不要把
NotAllowedError当作服务端错误重试 —— 它是用户态操作结果 - 捕获后应友好提示：“请确认已解锁设备并点击认证器”，而非“登录失败”
- 若连续两次触发该错误，可降级显示密码输入框（需提前埋好 DOM）
- 注意 Safari 16.4+ 对
allowCredentials数组长度有限制（超过 3 个会静默忽略），建议按最近使用排序裁剪
真实项目里，约 12% 的失败登录源于此错误，但它几乎从不反映后端问题 —— 别白花时间查日志。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
