------关于 OTP / TOTP 生成器
OTP 是两步验证里那串每隔几十秒就刷新的动态码，最常见的是基于时间的 TOTP（RFC 6238）。本工具在浏览器本地，根据你提供的 Base32 密钥实时生成 TOTP 验证码，并显示剩余有效秒数，支持自定义位数和周期。密钥只在本地参与运算、不上传，适合调试 2FA 接入、核对服务端实现或在没有手机时临时取码。例如输入共享密钥与当前时间，会生成 6 位 TOTP 验证码并显示剩余有效秒数，与 Authenticator 应用一致。接入两步验证时，先用它对照服务端实现确认时间步长与位数是否一致，能快速定位验证码不匹配的根源；请注意共享密钥等同于登录凭证，调试结束后应及时清理，正式环境仍建议配合限次尝试与备用码机制共同使用，降低被暴力尝试的可能。
这类口令的有效性依赖双方时钟接近，因此时钟偏差是部署时最常见的失败原因。生成端与服务端的时钟若相差超过允许的窗口，口令就会整体失效，而表现为「总是提示口令错误」。因此在排查这类问题时，应当先核对两端的时间是否同步，再检查密钥与算法参数，顺序反了会浪费大量时间。
两种工作方式的区别在于计数的来源，理解这一点才能选对方案。一种以时间步长作为计数依据，口令随时间自动变化，适合需要用户手动输入的场景；另一种以事件次数作为计数依据，每使用一次计数加一，适合硬件设备驱动的场景。前者对时间敏感，后者对调用次数敏感，混用会出现两端不同步的问题。
密钥的表示形式与长度需要与对方约定一致，这是对接时最容易出错的地方。同一段二进制密钥可以有多种文本表示，长度要求也各不相同，若一方按一种表示提供而另一方按另一种解析，生成的口令与服务端永远不一致。因此在配置密钥时应当明确说明编码方式与长度，而不是只给出字符本身。
使用窗口的宽度是一组需要权衡的参数，过窄与过宽都有代价。窗口过窄会让轻微的时间偏差直接导致失败，用户反复重试；窗口过宽则扩大了单个口令被重复利用的空间，降低安全性。因此窗口宽度应当结合实际的时钟同步质量来设定，并在两端保持一致，而不是单方面收紧或放宽。
这类口令只是第二重验证因素，它的价值建立在「与密码分离」这一前提上。若把它与密码一同存储在同一个位置，或通过同一条渠道传递，双重验证就退化为单重；此外一次性恢复码应当离线保存，因为它们是设备丢失后唯一的进入方式。因此在启用时应当把恢复码的保存方式一并交代清楚。
最后，它与短信形式的验证码有本质区别，不必混为一谈。短信码依赖运营网络，存在被拦截与换卡的风险，而本地生成的口令不经过网络传输，因此安全性更高但要求设备可用。理解这层差异有助于在选型时做出判断：面向安全性要求较高的场景应优先使用本地生成的方式。
实现原理
基于时间的动态码把共享密钥与当前时间步长一起送入哈希函数，再截断成固定长度的数字。因此生成结果只依赖三样东西：密钥、步长与当前时间。三者任一不一致都会连续失败——其中时间偏差最隐蔽，设备时间慢于一个步长就会一直对不上，这也是排查时应先校时的原因。
密钥（Base32）与步长 30 秒同一时间窗口内生成的 6 位数字相同；进入下一个窗口后数字改变（因此校验需容忍前后各一个窗口）使用方法
- 打开「OTP / TOTP 生成器」
- 输入待处理的内容并设置参数
- 根据需要调整输出选项
- 点击「生成」按钮，结果实时显示
- 复制或导出结果
使用场景
- 调试 2FA 接入 — 用服务端下发的密钥本地算 TOTP，核对你的验证逻辑是否与标准一致。
- 核对验证器 — 比较本工具与 Google/Microsoft Authenticator 生成的码是否相同，定位时间漂移问题。
- 应急取码 — 临时没有手机时，用已知密钥在浏览器里生成当前验证码登录。
- 自动化测试 — 在开发环境为带 2FA 的账号生成可预测的测试验证码。
- 排查时间偏差 — 观察剩余秒数和服务端拒绝情况，判断是否因时钟不同步导致校验失败。
常见问题
TOTP 和 HOTP 有什么区别？
HOTP（RFC 4226）基于递增计数器，每用一次步进一步；TOTP（RFC 6238）把计数器换成"当前时间除以周期"，所以验证码随时间自动刷新，是手机验证器的主流做法。
为什么我的码和服务端对不上？
最常见原因是设备时钟不同步。TOTP 严重依赖准确时间，几十秒的偏差就会算出不同的码。请校准系统时间，多数服务端也会容忍前后一个时间窗。
密钥为什么要用 Base32？
2FA 密钥常以 Base32 表示，因为它只用大写字母和数字、无易混字符，便于以二维码或文本分享。运算前工具会先把 Base32 解码回原始字节再做 HMAC。
默认是几位、多少秒刷新？
行业默认是 6 位数字、30 秒周期、底层用 HMAC-SHA1，这也是绝大多数验证器和服务的标准配置。部分系统会用 8 位或 SHA256，本工具可自定义匹配。
在浏览器里生成验证码安全吗？
运算本身在本地完成、密钥不上传，但把 2FA 密钥放进浏览器会削弱"第二因素"的隔离性。建议仅用于调试，长期使用仍以独立的验证器 App 或硬件密钥为宜。
生成的验证码总是不对，可能是什么原因？
按可能性排序：一是设备时间不准，这类验证码基于时间步长计算，时间偏差超过一个步长就会连续失败，应开启自动校时；二是密钥输入不规范，空格与大小写都应先规范化；三是步长设置与服务端不一致，常用值为三十秒但并非所有系统都如此。逐项核对后基本能定位。
同一个密钥能在多个设备上生成相同的验证码吗？
可以，只要密钥、步长与算法三者的参数完全一致。这既是便利也是风险：多一份副本就多一个泄露点，因此在多设备使用时，应确保每台设备本身有独立的解锁保护，并在设备丢失时及时撤销该密钥；服务端若支持，优先为每台设备登记独立密钥而不是共用一份。
生成的验证码和手机上的对不上？
TOTP 基于共享密钥 + 当前时间，两侧不一致通常是：设备时间偏差超过容差（±30 秒）、密钥录入时少了字符或大小写错误。先校准设备时间（NTP），再核对密钥——密钥错一位就永远对不上。