问题排查
验证码开头的 0，要不要填？
六位验证码以 0 开头，不能只输入后面五位。看看前导零为什么要保留，以及代码经过数字转换后为什么会变短。
要填。验证码开头的 0 也是其中一位，应按验证器显示的完整代码填写。六位还是八位取决于账号配置，不要把代码当成普通数值，也不要凭空猜测缺失的数字。
开头的 0 也是一位
| 填写内容 | 位数 |
|---|---|
| 012345 | 6 位，保留完整示例 |
| 12345 | 5 位，少了开头的 0 |
假设验证器显示 012345。这是用来说明格式的六位示例：从左到右共有六个位置，第一位就是 0。只填 12345，便少了一个位置。
不要用平时读整数的习惯来处理验证码。账号要求的位数属于代码格式的一部分，看到开头有 0，照着保留即可。
转成普通数值，格式就可能丢了
代码经过数值转换后，开头的 0 不再保留。例如在 JavaScript 中，将文字 '012345' 传给 Number()，得到的数值是 12345；再转回文字，也不会自动知道原先有六位。
这是数值转换的结果，不代表每个网页输入框都会这样处理。若粘贴后内容变短，先对照验证器里的当前完整代码和输入框中的实际内容，不要直接认定账号绑定出了问题。
标准中的公开样本，也有开头为 0 的代码
| 公开样本的表示 | 内容 |
|---|---|
| 完整八位结果 | 07081804 |
| 转成数值后的表示 | 7081804，原来的位数信息不再保留 |
RFC 6238 附录 B 列出了一组公开测试样本：使用文档给定的测试密钥、SHA1、30 秒步长、起点 T0 = 0，在 Unix 时间 1111111109 时，八位结果为 07081804。它的第一位 0 同样需要保留。
这里是八位测试样本，不能把它误当成日常账号的六位代码，也不能拿到真实登录页使用。RFC 4226 的参考实现同样会在结果前补 0，直到达到指定长度。
填写时，取当前完整的一组
在 Authenticator Cloud 中找到对应服务和账号，查看当时显示的完整验证码。复制或填写时一并保留开头的 0，避免先经过表格或其他中间工具做数值转换。
如果输入框已有上一组数字，先确认内容，再填入当前这一组。拿不准少了哪一位时，回到验证器重新取码，不要按猜测在前面补几个 0。浏览器里的取码方式可参阅复制与填充指南。
- 按当前条目显示的完整位数填写，不只看最后几位。
- 对照正确的服务和账号，不把两个同名条目的代码混用。
- 代码变短时，检查复制后到填写前是否经过了数值转换。
数字完整，网站却仍然提示错误？
前导零只是一个格式检查点。如果完整代码仍未通过，可继续按验证码错误的检查步骤核对账号、有效时间和绑定状态，不必先删除现有记录。
参考资料
详细设置步骤可参阅以上官方帮助。
