准备把 GitHub 验证器改到安令码时，先保留原方法
已经使用验证器登录 GitHub，准备改用安令码时，先不要删除旧条目或关闭整个两步验证。GitHub 官方文档提供在保留两步验证的情况下更换 TOTP 应用的方法。关键顺序是先配置新方法、用有效验证码验证并保存，再处理设备上的旧条目。
安令码的产品资料列出 TOTP、二维码与手动密钥添加能力，但本文没有对当前安装版本执行 GitHub 绑定实测，也不声称两者存在官方合作或认证。下文中 GitHub 侧的具体步骤依据 GitHub 官方文档，安令码侧应按当前正式版本实际提供的入口核对。
先确认你仍能进入正确的 GitHub 账号，并拥有管理该账号安全设置的权限。若已经完全无法登录，应改查 GitHub 的账户恢复方法，而不是照着正常更换流程继续。保留原设备与可用登录状态，能让你在新方法尚未完成时继续核对必要信息。
- 保留旧验证方法，直到新配置保存完成。
- 本文是账户侧核对流程，不是产品兼容实测报告。
- 无法登录时先进入官方恢复路径。
确认账户类型，避免在不适用的账号上找按钮
开始前先看清当前 GitHub 用户名和账号类型。GitHub 官方文档对普通个人账户与企业托管用户的两步验证管理有不同说明；企业托管场景可能由身份提供方和管理员管理。不要因为个人账户教程中出现某个按钮，就断言所有工作账号都应该显示同样入口。
如果你拥有多个个人与工作身份，先通过已确认的账号页面核对当前对象，再进入安全设置。浏览器里保留着登录状态，并不代表正在操作的就是你想迁移的那个账号。账户确认只需在自己设备上完成，不必把用户名、邮箱与安全设置全屏图发给他人代看。
对受组织规则约束的账号，先确认更换方法是否符合已有要求。本文不建议为获得按钮先退出组织或关闭两步验证，也不提供绕过管理员控制的步骤。范围不明确时，应向负责账号的人说明目标与当前界面，再决定是否继续配置。
- 先确认用户名与账户类型。
- 个人账户步骤不套用到受管理身份。
- 不通过关闭安全要求来解决入口差异。
在 GitHub 安全设置中选择编辑现有验证器
GitHub 当前官方更换方法说明，进入头像菜单中的 Settings，在 Access 区域打开 Password and authentication，再在 Two-factor methods 中找到要修改的方法并选择 Edit。配置了多种方法时，入口可能位于该方法的更多菜单中，应以当前页面实际显示为准。
这里要编辑的是现有验证器方法，而不是关闭整个两步验证。官方说明这种重新配置可以保留恢复码和要求两步验证的组织成员关系。不要把删除全部方法当成标准前置步骤，也不要因为想让流程更短就跳过页面要求的身份确认。
进入配置后，先确认页面仍在 GitHub 官方域名和正确账户范围。别人通过聊天发来的二维码或所谓迁移链接，不能替代从自己账号安全设置打开的内容。若页面来源、账号或提示与你预期不符，先停在录入密钥之前，避免把别人的设置误加到自己的验证器。
- 编辑对应验证器，不关闭整个两步验证。
- 从已登录账号的安全设置进入。
- 来源与账户有疑问时不继续录入密钥。
扫描二维码与手动密钥，都是同一份绑定秘密的载体
GitHub 官方文档提供扫描设置二维码或点击 setup key 查看 TOTP 设置密钥的方式。两者用于把生成验证码所需的信息交给验证器，不是可以随意分享的普通登录图。不要上传到在线二维码识别网站，也不要发给同事或所谓客服帮忙转换。
在安令码中，按当前版本实际提供的二维码或手动密钥添加入口操作。本文不编造按钮位置，也不保证每种平台都有相同扫描方式。若设备上不便扫码，可以先查看官方是否允许当前手动配置路径；不要为了传图方便，将完整设置二维码同步到不必要的聊天或共享相册。
录入完成后先核对条目指向的服务和账户，避免把新条目误认成另一个 GitHub 身份。条目名称只是帮助辨认的标签，不是账户侧已完成保存的证明。此时还需要回到 GitHub 完成验证码验证，才能继续判断新的方法是否已经被账户接受。
- 二维码与设置密钥都按秘密保管。
- 只在已确认的本机入口录入，不交第三方转换。
- 条目出现以后仍需完成账户侧验证。
手动配置时，核对 GitHub 给出的参数
如果确实采用手动配置，GitHub 官方文档列出其 TOTP 参数：类型为 TOTP，发行者为 GitHub，默认算法 SHA1，六位数字，周期 30 秒；设置密钥来自你自己的配置页面。账户标签包含 GitHub 与用户名，便于分清对应身份。不要把页面里的密钥示例或他人的截图内容当成自己的配置。
这些参数是 GitHub 当前文档给出的配置，不能据此要求所有其他网站采用同样数值。RFC 6238 说明 TOTP 生成端与验证端需要共享相应秘密和时间步长；一个验证器能够显示数字，并不说明它与当前网站使用了同一组参数。
若安令码当前界面无法明确核对所需字段，先查产品说明或保留原验证方法，不反复尝试猜参数。也不要为了让两台设备显示相同数字，把不同账户的密钥互相替换。手动配置的目标是准确使用本账户给出的设置，而不是找到一组看起来常见的数值。
- 参数来自当前 GitHub 官方配置与本人页面。
- GitHub 的默认值不推广到全部服务。
- 无法确认字段时保留原方法，先补充说明。
回到 GitHub 验证并保存，再确认新方法生效
完成录入后，从新条目读取当前验证码，输入 GitHub 的 Verify the code from the app 区域，再按官方流程保存。GitHub 特别说明，只有提交有效的新验证码并点击 Save，现有方法的变更才会生效。在此之前，不应替换或删除设备上的原验证条目。
提交前看清输入框属于 GitHub 配置页面，而不是聊天窗口或搜索栏。验证码用于这个正在进行的验证，不需要通过他人中转。若编码已经变化或页面返回错误，先记录可见提示，核对当前条目、参数与设备时间，不连续提交大量猜测值。
保存以后，回到账户安全设置确认目标方法已按预期更新。本文没有替你进行这次操作，因此不能把扫码完成或本地生成六位数写成绑定成功。保留“本地条目已添加”“账户验证码已接受”“设置已保存”三个状态，才能知道流程停在哪里。
- 有效验证码与 Save 都完成后才视为配置生效。
- 验证码只提交给当前官方配置页面。
- 本地条目、验证码验证与账户保存分别记录。
新方法核对完成后，再安排登录检查与旧条目整理
账户保存成功以后，可以在保留当前可用会话的前提下，按自己的正常方式核对新方法是否能参与登录。使用本人设备与准确账号，不在陌生电脑上测试。若有多个验证方式，记录实际使用的是哪一种，避免把其他备用方式的成功误当成新 TOTP 已经验证。
在新方法尚未确认前，不要清空旧设备或把所有现有会话退出。本文不会要求你制造一次完全锁定来测试恢复能力，也不保证每种账户环境的会话行为相同。检查的目的，是增加对当前配置的把握，不是主动丢掉仍然有效的访问途径。
确认后再决定怎样整理旧条目和设备，避免同名记录长期混用。是否删除、何时删除，应按实际新配置结果与备份安排处理；不要把删除某台设备上的条目，等同于从所有地方撤销某份秘密。账户侧的状态和本地资料的留存仍需要分别理解。
- 保留可用会话完成小范围核对。
- 记录实际使用的新验证方式。
- 新方法确认后再整理旧条目与设备。
保留备用恢复方式，但不为更换验证器随意重置
GitHub 官方建议为账号配置多种验证或恢复方法，减少丢失一种方式后无法进入账户的风险。重新配置现有 TOTP、而不关闭两步验证，不会要求重新生成全部恢复码。应先确认现有恢复资料能够安全找到，再决定是否另有理由更新它们。
恢复码与验证器生成的动态验证码用途不同，不能把恢复码录入 TOTP 设置密钥字段，也不要把一份旧验证码截图当成长期备用方法。本文不重复完整备份迁移教程，重点是避免在一次方法更换中同时改动太多恢复条件，导致最后说不清哪一项仍然有效。
如果恢复资料已经遗失，按 GitHub 官方恢复方法核对当前可用选项，不向本站或第三方提交密钥、恢复码和账号密码。团队账号的备用方式也应由明确负责的人管理，不把真实秘密写进多人共享的迁移检查表。记录可以说明资料由谁按规则保管，而无需记下其内容。
- 确认备用方式可找到，不无故全部重置。
- 恢复码不填入 TOTP 密钥字段。
- 交接记录写管理状态，不写真实秘密。
用不含凭据的核对记录结束这次配置
一份简短记录可以包含账号代号、检查日期、安令码平台与可见版本、采用扫码还是手动方式、GitHub 是否接受新验证码、设置是否保存，以及后续登录核对结果。不要记录二维码图片、密钥、当前验证码或恢复码。它们不需要进入普通任务说明。
如果流程没有完成，就写明停在哪一步，例如“新条目可生成验证码，GitHub 尚未接受，旧方法保留”。这样的状态比笼统写“迁移完成”更有用，也不会让接手者误删仍需使用的旧条目。尚未核实的兼容性或字段入口应留作具体待办。
继续操作前，可先打开 GitHub 官方更换两步验证方法文档确认当前步骤，再按安令码当前产品说明核对本地入口。本文没有进行账号登录实测，不保证一次配置适用于所有企业环境。以正确账户接受并保存新方法、可用访问途径仍明确为结束条件，才能完成一次可回查的更换。
- 记录结果与版本，不留凭据副本。
- 未完成时保留旧方法并写明停点。
- 官方账户步骤与本地产品入口分别确认。