2026 .NET 11 RC.3 邮件验证怎么测？

先划分验收证据，再判断邮件是否通过

本次测试验收的是自家 ASP.NET Core 应用的邮件验证流程，不是在验证 .NET 自带的邮件发送能力。不要把“注册接口返回成功”“发送方法被调用”“日志显示已发送”和“邮箱里确实收到邮件”合并成一个通过结论。

本次只需覆盖其中几层，就先在测试记录里写明范围。例如，持续集成环境只运行应用调用与邮件内容断言，实收由单独的受控环境执行。这样不会把测试替身的绿色结果误报为端到端通过。

准备 RC.3 环境，隔离测试身份与配置

官方下载页列出的 SDK 完整版本为 11.0.100-rc.3.26522.148；核对版本时，不要只看项目文件里的目标框架。

开始注册测试前，先完成以下准备：

• 在构建日志中保存 dotnet --info 输出，并记录 SDK、运行时与目标框架；确认本次测试实际选中了 RC.3，而不是机器上其他已安装版本。
• 检查仓库中的 global.json。它会影响 CLI 选择 SDK；若团队需要固定 SDK 版本，应同时检查本地开发机和 CI 的 SDK 安装情况。(微软 global.json SDK 选择说明)
• 使用专用测试数据库、测试账号和预发配置。不要把生产邮件凭据、真实用户地址或可识别个人身份的数据复制到测试环境。
• 确认测试邮件目标属于自家测试或已获授权的环境。确认链接的主机名应指向测试环境，避免误操作生产账号。
• 为每次运行生成可识别的合成测试数据，并把运行标识、应用日志、邮件捕获结果分别保存，便于定位不同环节的失败。

测试数据也应有明确的清理与访问规则。可以先阅读 temprapid 的数据处理说明，再按团队的数据分类要求决定哪些测试内容可以放入受控收件箱。不要把真实用户资料当作“更像生产”的替代品。

用集成测试替身检查应用调用与邮件内容

ASP.NET Core 官方集成测试方法使用 WebApplicationFactory<TEntryPoint> 启动被测应用，并创建 TestServer 供测试客户端调用。它适合验证应用路由和业务流程；邮件是否外部投递，仍取决于应用配置与发送链路，不能从 TestServer 的响应直接推出。(微软 ASP.NET Core 集成测试文档)

在自家应用中，先找到注册逻辑依赖的邮件发送接口。测试时，将该接口替换为能保存邮件内容的测试实现，然后使用 WebApplicationFactory 发起注册请求。示意代码如下，接口名与服务注册方式要换成项目自己的实现：

public sealed class CapturingEmailSender : IEmailSender
{
    public List<(string To, string Subject, string Body)> Messages { get; } = [];

    public Task SendAsync(string to, string subject, string body)
    {
        Messages.Add((to, subject, body));
        return Task.CompletedTask;
    }
}

测试发起请求后，检查捕获到的消息是否存在；断言目标地址是合成测试地址，确认链接的主机名和协议符合当前测试环境，并检查正文中是否包含自家实现要求的确认信息。若注册请求本身失败，应先查看请求响应、验证规则和应用日志，不要先把问题归因于邮件服务。

ASP.NET Core 账户确认文档区分了模拟确认与真实邮件发送场景：应用的邮件接口需要由项目实现并注册，示例中的模拟确认不能作为真实收件证据。(微软账户确认与密码恢复文档)

FAQ：区分模拟发送与真实收件

RC.3 阶段的集成测试能把邮件实收作为结论吗？

不能。WebApplicationFactory 和 TestServer 可以帮助启动自家应用并发起 HTTP 请求；如果邮件发送接口被测试替身接管，断言通过只能说明应用调用了接口、生成内容符合断言。要确认外部邮件实际到达，必须另从受控收件端检查邮件。

ASP.NET Core 邮件验证测试中，模拟发送和真实收件各自验证什么？

模拟发送把邮件交接替换成可检查的测试对象，适合验证收件地址、主题、正文和确认链接，不会替你验证外部投递链路。真实收件则从隔离环境发出邮件，再在受控地址查看实际到达与可读性；两类证据应分开记录，不能互相代替。

用 WebApplicationFactory 检查注册确认流程时，应断言哪些内容？

让测试客户端提交注册请求，并在自家邮件接口的测试替身中捕获消息。随后检查目标地址、确认链接指向测试环境、必要的主题或正文内容，以及应用响应和数据库中的预期状态。测试替身的捕获结果证明应用生成并交接了消息，不证明邮箱服务已收到邮件。

.NET 11 正式版发布后，RC.3 邮件回归要重新核对哪些环节？

先从官方发布与生命周期页面核实正式版状态，再检查项目 SDK、目标框架、ASP.NET Core 相关兼容性说明和测试依赖。随后重跑应用触发、邮件内容、受控实收、确认链接及账号状态用例；优先复测受版本变化影响或此前失败的环节，并保留环境和结果记录。

用受控收件确认实收，再检查账号闭环

完成应用侧断言后，再从隔离环境发起一封与本次运行关联的注册确认邮件。将测试运行标识、应用侧的发送记录，以及受控收件端的查看结果分开保存。应用日志写着“已发送”或发送接口返回成功，都不能代替收件端的实收记录。

实收检查时，至少确认邮件对应本次运行、目标地址正确、正文可读、确认链接指向测试环境。遇到未到达或内容异常，记录发生时间、测试地址、应用日志和发送端结果；不要用一次成功就推断所有邮箱环境都可正常接收。

收到邮件后，打开确认链接并核对应用响应与测试账号状态。链接过期、重复使用或数据库状态没有变化时，记录完整复现路径，并回到自家实现检查。确认链接有效期、重复使用规则应以产品代码和产品文档为准，不存在可以直接套用的统一默认值。

若测试场景使用临时收件箱，还应先核对地址可用条件与收件保留规则，避免邮件到了却因测试安排或收件箱状态而无法检查。可参考 temprapid 的收件期限说明；该页面只能帮助理解相关使用边界，不能代替本次测试的实际收件证据。

按失败证据分流，并在正式版后复跑

排查时按证据所在层处理，避免在错误环节反复改代码：

• 应用没有触发发送接口：从注册请求、验证条件、依赖注入和业务分支查起。
• 捕获到的内容不对：检查地址来源、链接构造所用的环境配置、编码与模板逻辑。
• 接口调用成功但收件端无邮件：记录为“未确认实收”；继续检查实际发送配置、外部发送结果和受控收件端，不把调用成功写成投递成功。
• 邮件到达但链接或账号状态异常：沿确认请求、令牌校验和账号状态持久化路径复现，分别记录响应与数据库观察结果。

截至 2026 年 11 月 5 日，微软文档称 .NET 11 正式版预计在 2026 年 11 月发布；正式日期仍需以之后的官方公告为准。(微软 .NET 11 版本概览) RC.3 生命周期页面列出的支持结束日期为 2026 年 11 月 10 日，因此不要把候选版本的测试结果当作正式版结果长期沿用。(微软 .NET 生命周期政策)

正式版发布后，先核对下载页、生命周期信息和版本兼容性说明，再决定哪些测试受变更影响。微软的 .NET 11 兼容性页面列出可能影响升级的行为变化，并提示其内容可能更新；对目标框架、依赖包或 ASP.NET Core 行为有影响的变更，应优先重跑相关回归用例。(微软 .NET 11 兼容性变更列表)

如果应用侧测试已经通过，但还需要验证自家产品的注册邮件是否实际到达，受控测试收件地址可以作为单独验收方案。若只是临时注册、试用或接收一次验证邮件，temprapid 提供免注册、即开即用的临时邮箱，可减少把主邮箱暴露给测试邮件的需要；它不适合银行、支付、政务等需要长期找回的账号，也不适合必须持续收信或回复邮件的流程。

常见问题

.NET 11 RC.3 的集成测试能证明确认邮件已经进了收件箱吗？

不能。WebApplicationFactory 和 TestServer 可以帮助启动自家应用并发起 HTTP 请求；如果邮件发送接口被测试替身接管，断言通过只能说明应用调用了接口、生成内容符合断言。要确认外部邮件实际到达，必须另从受控收件端检查邮件。

ASP.NET Core 邮件验证测试里，模拟发送和真实收件有什么区别？

模拟发送把邮件交接替换成可检查的测试对象，适合验证收件地址、主题、正文和确认链接，不会替你验证外部投递链路。真实收件则从隔离环境发出邮件，再在受控地址查看实际到达与可读性；两类证据应分开记录，不能互相代替。

用 WebApplicationFactory 测注册确认邮件流程，应该断言哪些内容？

让测试客户端提交注册请求，并在自家邮件接口的测试替身中捕获消息。随后检查目标地址、确认链接指向测试环境、必要的主题或正文内容，以及应用响应和数据库中的预期状态。测试替身的捕获结果证明应用生成并交接了消息，不证明邮箱服务已收到邮件。

.NET 11 正式版发布后，RC.3 阶段的邮件回归要复核什么？

先从官方发布与生命周期页面核实正式版状态，再检查项目 SDK、目标框架、ASP.NET Core 相关兼容性说明和测试依赖。随后重跑应用触发、邮件内容、受控实收、确认链接及账号状态用例；只重测受版本变化影响或此前失败的环节，也要保留环境和结果记录。