UD5工具箱
什么是 Web OTP API？它与传统的短信验证码有什么区别？
Web OTP API 是 W3C 制定的浏览器标准规范，允许网页通过 JavaScript 调用浏览器原生能力来自动读取短信中的验证码。与传统短信验证码相比，Web OTP API 最大的优势是自动化：用户不再需要手动打开短信、记忆验证码、然后切换回网页输入，而是由浏览器自动完成从短信读取到验证码填入的全部过程。这将原本需要 3 步操作的验证流程简化为 1 步，显著提升了用户体验。此外，Web OTP API 的域名匹配机制还能有效防止验证码被恶意网站截获，安全性也有所提升。
Web OTP API 要求短信遵循什么样的格式？
Web OTP API 要求短信内容中包含
@domain#code 这一核心模式。其中 @ 后面跟的是发送验证码的网站域名（例如 @example.com），# 后面跟的是数字验证码（例如 #123456）。完整的短信示例可以是：「您的验证码是 @example.com#123456，有效期 5 分钟。」短信中可以包含其他文字内容，但 @domain#code 模式必须完整存在。域名必须与当前网页的域名精确匹配，浏览器才会自动填入验证码。目前哪些浏览器支持 Web OTP API？最低版本要求是什么？
截至当前，Web OTP API 主要在 Android 平台的 Chrome 浏览器中得到完整支持，最低版本要求为 Chrome 84。这意味着使用 Android 设备并运行 Chrome 84 或更高版本的用户可以正常使用 Web OTP 自动填入功能。iOS 平台的 Safari、以及 Firefox、Opera 等其他浏览器目前尚未支持该 API。在不支持的浏览器中，Web OTP API 的调用会抛出异常或返回 undefined，开发者需要实现降级方案（如传统手动输入验证码）来保证所有用户都能完成验证流程。
使用 Web OTP API 是否必须通过 HTTPS 协议？localhost 可以吗？
是的，Web OTP API 必须在安全上下文（Secure Context）中才能使用，这意味着页面需要通过 HTTPS 协议加载。浏览器会拒绝在非安全上下文中调用
navigator.credentials.get()。不过，在本地开发环境中，localhost 和 127.0.0.1 等本地回环地址会被浏览器自动视为安全上下文，无需配置 SSL 证书即可正常使用 Web OTP API。这为开发者的本地测试提供了便利。在生产环境中部署时，请确保服务器已正确配置 HTTPS 证书。如何处理用户长时间未收到验证码导致的超时问题？
在实际项目中，短信可能因网络延迟、运营商问题等原因未能及时送达。推荐使用
AbortController 来处理超时场景。具体做法是：创建一个 AbortController 实例，将其 signal 传递给 navigator.credentials.get() 方法，然后通过 setTimeout 设置超时时间（通常 30 到 60 秒）。超时触发时调用 controller.abort() 取消请求，并捕获 AbortError 异常，向用户显示「验证码获取超时，请重试」等友好提示。同时，应提供重新发送验证码的按钮，让用户可以主动重试。本工具的「测试超时处理」功能可以演示这一完整的超时处理流程。Web OTP API 与 Android 原生的 SMS Retriever API 有什么区别？
两者的核心区别在于应用层面和实现方式。Web OTP API 是浏览器层面的标准，适用于所有基于浏览器的网页应用（包括 PWA），由浏览器厂商负责底层实现，开发者只需调用 JavaScript API 即可。SMS Retriever API 是 Android 平台的原生 API，仅适用于 Android 原生应用，需要在 Java/Kotlin 代码中集成，并且要求应用配置 App Signature 以验证短信来源。在功能上，两者都实现了短信验证码的自动读取，但 Web OTP API 的使用门槛更低、适用范围更广。对于同时有 Web 和 Android 应用的项目，可以分别采用对应的方案。
短信中的域名匹配规则是怎样的？是否支持子域名？
Web OTP API 的域名匹配采用精确匹配（exact match）规则。短信中
@ 后面的域名必须与当前网页的域名完全一致。例如，短信中写的是 @example.com，那么当前网页的域名必须也是 example.com，不支持子域名匹配（即 sub.example.com 不会匹配 @example.com）。这意味着如果项目有多个子域名，需要为每个子域名单独配置短信中的域名信息。这种严格的设计是为了最大程度保障安全性，防止跨域的验证码误填。开发者在配置短信模板时，请务必确保域名与实际发送验证码的网站域名一致。PWA 应用中可以使用 Web OTP API 吗？有什么需要注意的？
可以。PWA（渐进式 Web 应用）运行在浏览器环境中，Web OTP API 的行为与普通网页完全一致。只要 PWA 应用部署在 HTTPS 环境下（满足安全上下文要求），就可以正常使用
navigator.credentials.get() 方法。需要注意的是，PWA 应用在离线状态下无法使用 Web OTP API，因为该 API 需要浏览器与底层短信系统通信。另外，如果 PWA 以「添加到主屏幕」的方式运行，部分浏览器可能会将其视为独立应用，此时 Web OTP API 的行为可能略有差异，建议在目标平台上进行充分测试。总的来说，PWA 与 Web OTP API 的兼容性良好，是推荐的技术组合。在实际项目中如何优雅地处理 Web OTP API 不支持的情况？
推荐采用渐进增强（Progressive Enhancement）的策略。在代码中首先检测
navigator.credentials 对象是否存在，以及其 get 方法是否支持 otp 参数。如果浏览器支持 Web OTP API，使用自动填入功能提升体验；如果不支持，则回退到传统的手动输入验证码方式。具体实现中，可以将 Web OTP API 的调用封装在一个 try-catch 块中，捕获 TypeError（API 不存在）或 NotAllowedError（权限被拒绝）等异常，然后展示手动输入界面。同时，在页面上可以添加一个提示，告知用户当前浏览器不支持自动填入，建议升级到 Chrome 84 以上版本以获得更好的体验。Web OTP API 获取的验证码安全性如何？是否会被恶意网站窃取？
Web OTP API 在设计上具有多重安全保障机制。首先，域名匹配机制确保验证码只能在合法的网站上被自动读取——浏览器会严格比对短信中的域名与当前网页域名，只有完全匹配时才会填入验证码。其次，Web OTP API 只能在安全上下文（HTTPS）中使用，防止中间人攻击。此外，浏览器在显示验证码填入提示时会明确告知用户正在操作的网站域名，用户可以确认后再授权。从攻击面角度来看，恶意网站无法通过 Web OTP API 窃取其他网站的验证码，因为域名匹配校验会在浏览器层面被拦截。整体而言，Web OTP API 的安全性优于传统的手动输入方式，因为手动输入过程中用户可能会被钓鱼网站欺骗。