HTML无法直接调用生物识别，必须通过JavaScript调用WebAuthn API（如navigator.credentials.get()）在HTTPS或localhost环境下触发系统验证，且需服务端参与challenge校验。
HTML 本身不能直接调用指纹或面容 ID
浏览器不提供原生 HTML 标签（比如 <input type="biometric">）来启用生物识别。所谓“生物识别开关”其实是前端调用 Web Authentication API（WebAuthn）触发系统级验证，HTML 只负责承载按钮或占位元素。
常见错误现象：Uncaught TypeError: navigator.credentials.create is not a function —— 浏览器不支持 WebAuthn，或页面未运行在 HTTPS/localhost 环境下。
- 必须部署在 HTTPS 或
localhost，否则navigator.credentials为undefined - 不能靠纯 HTML 实现，必须配合 JavaScript 调用
navigator.credentials.get() - 移动端 Safari/iOS 需 iOS 16.4+，Chrome Android 需 75+，旧版直接静默失败
用 button 触发 WebAuthn 登录（最简可用路径）
实际开发中，“开关”本质是一个带事件监听的 <button>，点击后调用 navigator.credentials.get() 请求系统弹出面容/指纹确认框。
示例代码片段（仅核心逻辑）：
立即学习“前端免费学习笔记（深入）”；
document.getElementById('bio-login').addEventListener('click', async () => {
try {
const assertion = await navigator.credentials.get({
publicKey: {
challenge: new Uint8Array([/* 服务端下发的随机数 */]),
allowCredentials: [/* 指定密钥 ID 列表，可选 */],
userVerification: 'preferred'
}
});
// 发送 assertion.response 到后端验证
} catch (err) {
console.error('Biometric auth failed:', err.name); // 如 'NotAllowedError'、'NotSupportedError'
}
});-
userVerification: 'preferred'表示优先走生物识别，但允许 fallback 到 PIN/密码；设为'required'会强制要求验证用户身份（部分设备可能拒绝） - 服务端必须生成并校验
challenge，前端硬编码固定值会导致安全漏洞 - 若用户取消弹窗，抛出
NotAllowedError，不是 bug，需友好提示“已取消”而非报错
如何判断设备是否支持生物识别登录
不能只检测 navigator.credentials 是否存在，还要检查认证器是否实际支持用户验证（即是否配置过指纹/面容 ID）。
可靠判断方式：
const isBioAvailable = async () => {
if (!window.PublicKeyCredential || !navigator.credentials) return false;
try {
// 尝试探测是否能创建条件性断言（不弹窗）
const hasAuthenticator = await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable?.();
return !!hasAuthenticator;
} catch {
return false;
}
};-
PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()是目前最准的探测函数，但 Safari 直到 iOS 17.4 / macOS 14.4 才支持 - 旧版 Safari 或 Chrome 用
get()+timeout模拟探测风险高，容易误判或触发无意义弹窗 - 即使返回
true，也不代表本次调用一定成功——用户可能临时关闭了 Face ID 设置
为什么不用第三方 SDK 封装这个流程
很多项目引入 @github/webauthn-json 或 simple-webauthn，但它们只是语法糖，底层仍是 navigator.credentials.get()。过度封装反而掩盖关键细节。
- SDK 通常默认
userVerification: 'required'，导致部分安卓设备直接报错UnknownError，而原生 API 改成'preferred'就能过 - 错误映射混乱：比如把
SecurityError错标为“浏览器不支持”，实际可能是 HTTP 协议问题 - 调试时看不到原始
assertion.response结构，排查签名验证失败困难
真正需要关注的只有三件事：HTTPS 环境、challenge 的生成与校验、用户取消行为的处理。其余都是包装层噪音。
生物识别不是开关，是请求；不是控件，是对话。每次调用都依赖系统策略、设备设置、用户意愿，任何想把它当 checkbox 来 bind 的思路，都会在真实机型上卡住。
