GitLab 登录用的 Email OTP 验证码有效期为 60 分钟；这只能说明验证码的有效时间，不能证明邮件已送达，也不能证明登录已完成。GitLab 官方二步验证文档说明了这一有效期。更稳妥的验收方案是分层进行：先在自家隔离环境核对 Email OTP 配置和登录逻辑，再用受控测试收件地址验证邮件到达与登录闭环。 GitLab.com 的 rollout 不代表 Self-Managed 默认启用；临时邮箱不应接管生产或重要账号。
适合需要核对实例配置的 GitLab Self-Managed 管理员；需要验收验证码收件和登录闭环的 QA 工程师；以及需要区分邮件捕获、应用验证结果与真实收件证据的开发者。
GitLab.com 与自托管实例的边界
GitLab.com 的 Email OTP rollout 与自托管实例的设置是两件事。官方文档说明，GitLab.com 从 2026 年 1 月起分阶段 rollout Email OTP，并自 2026 年 4 月起对用户名和密码登录要求 MFA；若用户未配置其他因素，Email OTP 可能作为第二因素。GitLab Email OTP 开发文档与官方二步验证说明描述了 GitLab.com 的 rollout 背景，不能用来推定自托管实例的默认状态。
Self-Managed 的功能受实例设置控制。GitLab 官方说明，email_otp_enabled 是实例级开关，GitLab 19.1 引入该设置，GitLab 19.2 移除了旧功能标志；自托管实例的功能状态应按当前版本和实例设置核实，而不是照搬 GitLab.com 的登录体验。应用设置 API 文档记录了相关设置边界。
另外，Email OTP 是登录验证路径，不等于新用户注册确认、身份核验、验证器 TOTP 或 WebAuthn。账户邮件验证也可能由锁定或新 IP 等情况触发；若验收目标没有先界定清楚，测试结果很容易把不同的验证流程混在一起。账户邮件验证文档列出了这类触发场景。
| 要验收的环境或事项 | 应核对什么 | 不能由此推断什么 |
|---|---|---|
| GitLab.com | 当前账号是否进入 Email OTP 流程，以及适用的 rollout 状态 | Self-Managed 的默认配置 |
| GitLab Self-Managed | 当前版本、实例级开关和登录策略 | GitLab.com 的 rollout 时间表 |
| GDK | 本地应用设置、捕获邮件和登录结果 | 外部邮件已送达真实收件箱 |
管理员：确认实例配置边界
管理员如何在 Self-Managed 实例中核验邮件 OTP？ 先确认测试版本和实例范围，再按该版本对应的官方说明核对开关，最后用隔离账号验证登录路径。不要直接在生产实例或生产管理员账号上试切设置。
- 在管理后台查看
Admin > Settings > General > Sign-in restrictions，记录 Email OTP 和账户锁定时邮件验证的设置状态。官方管理文档说明，允许用户配置 Email OTP 时，需要同时启用这两项设置。GitLab 登录限制说明 - 若通过 API 核验，使用管理员权限读取实例设置，并记录
email_otp_enabled与require_email_verification_on_account_locked等相关值。应用设置变更可能受缓存影响，不能假定保存后立即对所有请求生效；API 文档给出的默认设置缓存时间为 60 秒。 - 核对实例策略是否要求使用 TOTP 或 WebAuthn。Email OTP 不应被当作能满足所有二步验证策略的替代方式；具体适用条件以对应版本的官方文档为准。
- 将“允许用户启用”和“要求用户必须使用”分开记录。只确认开关可用，不代表已验证账号会被要求走 Email OTP。
隔离测试环境要先准备哪些条件？ 测试对象应是自家隔离实例中的非生产账号，并提前确定本次要证明的是验证码生成、邮件到达，还是输入验证码后登录成功。GDK 测试配置可参考官方 Email OTP 开发文档，但不要把开发文档中的本地设置直接视为生产建议。
| 测试层 | 可用方法 | 能证明的结果 | 不能单独证明的结果 |
|---|---|---|---|
| 应用与登录逻辑 | 隔离账号触发密码登录，观察是否进入验证码步骤 | 登录请求进入预期验证路径 | 邮件到达外部邮箱 |
| 本地邮件捕获 | 在 GDK 或本地测试设施查看捕获邮件 | 邮件内容进入捕获器，可检查收件人和本次测试对应关系 | 真实邮件服务完成外部投递 |
| 受控测试收件 | 使用测试账号可访问的收件地址收取邮件，再提交验证码 | 邮件到达该收件端，并可继续验证登录 | 其他实例、其他地址也一定兼容 |
开发者：分开记录应用状态与邮件证据
捕获器收到验证码后，怎样判定登录闭环已经通过？ 需要继续提交验证码，并观察应用是否建立登录会话；捕获器里有邮件，只能证明邮件进入了捕获环境。它不能单独证明外部投递成功，也不能证明验证码被应用接受。
可按以下检查顺序执行，每一步都使用自家实例的隔离测试账号：
- 记录实例版本、目标主机、测试账号标识和当前 Email OTP 设置，避免后续把不同环境的记录拼在一起。
- 使用该账号触发用户名和密码登录，确认密码通过后是否进入邮件验证码步骤。若没有出现，先回查实例开关、账号因素和登录策略。
- 在本地捕获器或受控邮箱中检查邮件的收件对象、主题、验证码内容和触发时间，确保邮件属于这次登录请求，而不是前一轮测试留下的旧信。
- 提交收到的验证码，记录页面提示和应用最终状态。仅看到验证码输入页面、接口返回或邮件正文，都不等同于会话建立。
- 核验登录后的会话状态，并把结果与同一测试账号、同一请求、同一封邮件关联保存；测试重复执行时，旧邮件应与本轮证据区分。
- 若排查 GDK 或应用日志，按官方开发文档所述的 Email Verification 事件与会话事件检查；不要自行假设不同版本都会输出完全相同的日志字段。
这组记录至少要把三个状态分开：密码认证后的应用状态、验证码提交后的应用结果、浏览器是否获得登录会话。这样，当邮件到达但登录没完成时，排查方向会落在验证码验证与会话闭环，而不是反复把邮件发送当作唯一问题。
QA：用受控收件验证完整闭环
测试收件箱没有出现验证码邮件时，优先排查什么？ 先确认测试账号填写的收件地址、实例实际使用的邮件配置和触发的验证类型；再看本地捕获器或受控邮箱是否收到本轮邮件，最后检查垃圾邮件文件夹和实例日志。若邮件尚未到达，不要用“验证码无效”来描述问题；那是不同的故障状态。
遇到重发时，按 GitLab 对应版本的官方行为核对。GitLab.com 的二步验证排障说明指出，重新发送会生成新验证码并使前一枚失效，因此应等待当前邮件再提交，不要在多封邮件之间混用验证码。这个 GitLab.com 说明不能自动推广为所有自托管版本的统一行为；自托管验收应记录实例版本并按对应资料复核。
决策条件：
- 若目标只是检查登录逻辑，且邮件被本地捕获器接收，则先用捕获器完成内容和应用状态核对；结论限定为“本地捕获测试通过”。
- 若目标包括确认收件链路，则使用测试账号可控的受控收件地址；捕获器结果不能替代真实收件证据。
- 若目标是证明登录闭环，则必须提交该轮验证码，并确认会话建立；邮件到达或验证码页面出现都不足以单独通过验收。
- 若测试账号属于生产管理员、重要工作账号，或之后需要依赖它找回访问权限，则回退到长期可控的组织邮箱，不用临时地址。
测试地址的选择也应和后续访问需求匹配。若账号需要长期找回，先看按后续来信选择邮箱类型；临时收件地址和长期备用地址的隐私边界不同，避免把短期测试方案误当成账号恢复方案。
安全审查：保留证据并限定结论
发布负责人应保存足以复核的证据：实例类型与版本、Email OTP 相关设置、测试账号的隔离属性、邮件捕获或受控收件记录，以及验证码提交和登录会话结果。记录中尽量使用测试标识，不要保留不必要的真实姓名、个人邮箱或其他 PII。
测试结束后清理测试账号凭据、捕获邮件和可访问的验证码数据；同时标明结论只适用于被测实例和配置，不能据此证明 GitLab.com rollout 状态、其他自托管实例设置或所有收件地址的兼容性。GitLab 更新 Email OTP 配置、rollout、验证码处理或测试文档后，应重新核对相关步骤，而不是沿用旧截图和旧设置名。
截至 2026 年 10 月 26 日，本文依据 GitLab 官方 Email OTP 开发文档、二步验证及排障文档、登录限制、应用设置 API 和账户邮件验证说明核实；若官方文档或设置在之后发生变化，应按目标实例版本重新确认。
如果验收对象只是自家隔离实例中的测试账号，临时收件地址可以作为受控方案之一；若收件地址必须长期可访问，应选择长期管理的邮箱或备用地址。需要快速收取测试邮件时，可先查看 CloneInbox 的临时收件方式，确认其免注册、即开即用等能力与限制后再决定是否适用；不要把它用于 GitLab.com 或其他重要账号。
让购物通知有自己的入口
用 CloneInbox 转发别名持续接收普通通知；只需一次短期验证时，再选择临时邮箱。