为什么一次邮箱变更会悄悄中断组织通知
准备停用旧邮箱的负责人通常只关注一件事：邮件改投到哪里。但 GitHub 可能让同一个地址承担至少三种不同角色，而它们出问题的方式各不相同。
| 角色 | 作用 | 停用旧邮箱后可能出什么问题 |
|---|---|---|
| 登录与恢复 | 让你验证身份并恢复账号 | 你可能被锁在账号之外 |
| 已批准的通知邮箱 | 当投递被限制到某个域名时，接收组织邮件 | 组织通知不再送达你 |
| 公开提交身份 | 在提交元数据中显示一个地址 | 最多只是显示层面；它不负责投递邮件 |
请把这些当作彼此独立的检查项。改动其中一项，并不能确认其他项也没问题。
域名限制是最容易被忽略的部分
如果你的组织将通知投递限制在已批准域名，你打算保留的地址必须属于该域名，并且必须通过验证。
当组织将通知投递限制在该域名时，GitHub 要求验证已批准域名下的邮箱。来源
因此，你自己控制的个人地址并不自动符合要求。停用旧邮箱前，先向组织所有者确认哪个域名已获批准，再确认你的替代地址属于该域名，并在 GitHub 邮箱设置中显示为已验证。
还有一条限制排除了最省事的变通做法：
GitHub 不允许通过一次性邮箱服务完成验证。来源
如果替代收件箱是一次性或临时服务，请另选地址。把邮件转发到一次性收件箱，只是多了一跳，问题依旧。
不要把提交地址与通知地址混为一谈
提交记录可以显示一个 no-reply 地址，这是有意为之。
no-reply 提交作者地址是一种隐私保护机制，不能替代可正常收信且已验证的通知邮箱。来源
检查设置时这一点很重要：在提交历史里看到 no-reply 地址，并不能说明组织邮件能否送达你。请分别检查通知地址和登录地址。
停用旧邮箱的检查清单
请按顺序完成以下步骤，在全部完成前不要关闭旧邮箱。
- 列出旧地址承担的角色。 登录、恢复、通知投递和公开提交身份。记下旧收件箱目前承担其中哪些角色。
- 先添加替代地址。 在删除任何内容之前，先把新地址添加到账号并完成验证。
- 确认已批准域名。 向组织所有者询问哪个域名获准用于通知投递，并检查你的替代地址是否匹配。
- 排除一次性服务。 如果替代地址依赖临时邮箱提供商，请另选地址。
- 让恢复渠道保持在你控制之下。 确保在整个变更过程中，你仍能在自己控制的地址收到登录和恢复邮件。
- 发送测试。 触发一条低风险的组织通知，确认它到达新收件箱。
- 最后才停用旧收件箱。 在你亲眼看到真实邮件到达替代地址之前，保留一条回退路径。
决策表：替代地址准备好了吗？
| 问题 | 是 | 否 |
|---|---|---|
| 新地址是否已在账号上验证？ | 继续 | 先验证 |
| 它是否属于组织的已批准域名？ | 继续 | 询问所有者；暂不停用 |
| 它是否属于一次性服务？ | 另选地址 | 继续 |
| 你是否已在那里收到真实的组织通知？ | 停用旧收件箱 | 在收到之前保留两者 |
常见失败路径
- 验证了错误的地址。 你确认了个人地址，但组织只向已批准域名投递。邮件会悄悄中断。
- 过早移除旧地址。 账号本身可能仍需要验证邮件。在新地址得到证实之前，保持旧收件箱开启。
- 轻信提交身份。 整洁的 no-reply 提交地址看起来像一切已配置好，但它与通知投递毫无关系。
- 使用一次性收件箱。 它无法用于受限投递的验证，也不是接收恢复邮件的好地方。
如果你无法确认已批准域名，请把这次迁移视为未完成。向组织所有者询问，不要猜测。
本指南没有说明什么
本文不描述 GitHub 当前的菜单标签、确切的字符规则或每种计划类型的步骤。这些细节会变化，应在你自己的设置和组织文档中核对。上述检查关注的是角色与验证，而不是某个具体界面布局。
相关的下一步任务
组织邮件稳定后，你可能想知道还有哪些账号绑定在你准备停用的地址上。这与通知投递是另一个问题，相关指南见通过邮箱地址查找账号。
如果你想先快速扫描公开个人资料，TraceSeek 可在 3,000+ 个平台上检查用户名，首次扫描免费且无需注册。公开匹配只是线索，不能证明账号属于同一个人，重要信息请直接核实。