应用测试已经通过，受控收件箱里却还没有邮件？
最快的验收结论：Spring Boot 4.2.0-RC2 是候选版本，不要只为邮件测试直接替换稳定版；可以在隔离环境检查自家应用的邮件生成和发送配置，但真实收件要用受控地址另行确认。测试通过不等于生产邮件必达。
正在隔离评估候选版本的 Java 开发者：确认自家应用的邮件链路是否按预期工作。
负责邮件回归的 QA：需要把应用断言与收件端证据分开记录。
准备升级的独立开发者或技术负责人：判断是继续试用候选版本，还是留在稳定版。
最后更新于 2026 年 11 月 7 日；版本信息核实自 Spring 官方 RC2 发布公告及官方版本文档。
先确定 RC2 值不值得测
Spring 官方公告确认 Spring Boot 4.2.0-RC2 于 2026 年 11 月 6 日发布。公告列出本次版本包含 99 项增强、文档改进、依赖升级与缺陷修复，但所列变更并未宣称新增邮件测试功能；因此，不能把 RC2 发布当成邮件能力发生变化的证据。官方文档将 4.2.0-RC2 标为仍在开发中的预览版本，并将 4.1.2 列为稳定版。先核对官方版本状态：如果没有明确的候选版评估需求，邮件验收不构成单独升级理由。
| 评估对象 | 适合回答的问题 | 不能据此推出的结论 |
|---|---|---|
| RC2 隔离测试 | 自家应用在当前候选构建和配置下，是否按预期生成并尝试发送邮件？ | 生产环境邮件必然到达 |
| 稳定版回归 | 当前稳定版本的既有邮件流程是否仍符合预期？ | RC2 与稳定版行为完全相同 |
| 受控地址收件核验 | 本次测试邮件是否实际出现在指定收件端？ | 其他收件服务或生产用户也会收到 |
邮件测试只针对自家产品或获授权环境。不要连接生产邮件服务器、把测试流量发给真实用户，或在测试内容里放入真实个人信息。
隔离配置，再触发流程
先选一个隔离的开发或预发环境，确认当前激活的 profile、配置文件加载顺序和邮件服务器地址。重点检查凭据是不是来自测试专用的环境变量或密钥配置，而不是生产配置；不要只凭配置文件名称判断环境安全。
Spring Boot 的邮件文档说明，存在 spring.mail.host 和相关邮件依赖时，框架可以创建默认 JavaMailSender，并允许通过 spring.mail 配置项调整。文档也提醒，部分超时默认值可能是无限的。验收时要核对项目实际加载的值与运行环境，不要把“配置文件里写了”当成“当前进程确实使用了”。可对照Spring Boot 邮件发送配置文档逐项检查。
为本次运行设置容易辨认、但不含用户隐私的标记，例如测试账号标识或主题前缀。让标记能同时出现在测试记录与邮件主题中，以便区分重跑结果。日志只保留必要的状态和关联标记，不要打印邮件凭据、验证码或完整验证链接；这些内容可能被持续保存在构建产物、测试报告或日志平台中。
用应用断言验收生成与调用
通过自家注册、密码重置或通知流程触发邮件。先检查业务代码是否生成了预期的收件人、主题和正文，再检查应用是否走到发送路径。把断言对准实际需求：例如校验目标地址、主题中的运行标记，以及正文是否包含预期的验证入口。若正文含敏感令牌，只校验必要片段，不要把令牌写入测试报告。
JavaMailSender 是 Spring Framework 提供的邮件发送抽象，支持普通邮件发送接口扩展出的 MIME 邮件能力。具体测试应跟随项目实际调用的发送方法：若在单元测试中替换为模拟对象，就验证应用是否按预期调用它、传入内容是否正确；若应用使用 MimeMessage，断言也要检查该类型对应的主题、收件人和正文。相关接口与邮件准备方式可参照Spring Framework 邮件文档。
需要加载 Spring 应用上下文时，可以采用官方文档介绍的 @SpringBootTest 等测试方式；但测试上下文能否启动，只回答配置和应用组件是否可用，不会自动证明外部收件端已经收到邮件。对框架测试注解的使用，可复核Spring Boot 测试应用文档。
验收过程中的常见判断
- 邮件没有生成：检查业务分支、测试数据和触发条件，先确认流程是否走到创建邮件的代码。
- 生成了，但发送路径未调用：核对发送服务是否被替换成模拟对象、依赖是否注入正确，以及测试是否覆盖真实调用分支。
- 发送调用发生了，但没有收件证据：继续检查测试配置与邮件服务器侧的可观察结果；不要把调用断言改写为“已投递”。
这些判断是面向自家应用的排查建议，不是 Spring 对外部投递的保证。
JavaMailSender，它验证的是应用行为，不会连接外部邮件服务器。报告中应明确写出使用了模拟对象还是实际发送配置，避免把两种测试结果混为一谈。FAQ：把应用结果与真实收件分开
RC2 邮件测试应该放在什么环境？
放在与生产隔离的开发或预发环境，并显式检查当前激活的 profile、邮件服务器地址和凭据来源。测试收件目标也应专门识别，避免测试代码或配置误把邮件发给真实用户。候选版本测试通过后，仍需在稳定版本和目标部署环境分别复核。
应用测试通过，怎样确认测试收件箱真的收到？
应用断言只能证明它覆盖到的逻辑运行，例如发送方法被调用；它本身不能读取外部收件箱。使用受控地址查看邮件是否出现，再对照本次运行标记、收件人、主题和关键内容。把收件端核验记录为单独证据，不要用模拟对象的断言替代。
JavaMailSender 调用成功，是否就代表邮件已送达？
不代表。应用侧调用结果和邮件服务器接受消息属于发送链路证据，不等于目标收件箱已经展示邮件。验收记录要分开写明应用调用情况、发送端可观察结果和受控收件端的实际结果；若没有最后一项，就不能声称完成了真实收件验收。
候选版本测试通过，可以代替稳定版回归吗？
不能。结果只适用于本次候选构建、测试配置和已覆盖流程，不自动适用于之后的候选构建、稳定版或生产环境。升级计划继续推进时，应在稳定版发布或实际升级后重新跑关键邮件流程，并再次核验受控收件。
查看发送结果，再核对受控收件
检查本次运行实际使用的邮件配置与可观察的发送结果。这里要分清“发送配置存在”“应用调用发送路径”“发送端返回或记录结果”三件事；它们提供的证据不同。排查时按“邮件未生成—发送配置未生效—外部收件尚无证据”的顺序定位，不要只凭一条应用日志就判定投递成功。
SMTP 协议说明，服务器在接受邮件后承担继续投递或报告失败的责任；这并不等于邮件已经出现在最终用户看到的收件箱中。可以参照 RFC 5321 对 SMTP 接受责任和后续投递的说明，把“发送端已接受”与“收件端已看到”记录为不同状态。
如果验收目标包含外部收件，就用受控测试地址完成最后一段核验。查看邮件是否实际到达、是否可读，并比对收件人、主题和本次运行标记。若只有发送端记录、没有收件箱证据，结论应写“发送路径有结果，实际收件未核实”，不要用固定等待时长或猜测成功率补足证据。
收尾时按证据作出 RC2 结论
完成测试后，用这份清单逐项记录；有任一项无法确认，就把结论限制在已经观察到的范围内。
- [ ] 记录候选构建标识、运行环境与激活的测试 profile。
- [ ] 确认邮件配置来自测试环境，未指向生产服务器或真实用户。
- [ ] 记录邮件是否生成，并核对本次运行对应的收件目标、主题与关键内容。
- [ ] 写明发送路径使用模拟对象还是真实发送配置，以及实际观察到的结果。
- [ ] 若要证明真实收件，记录受控收件端是否收到可识别的邮件。
- [ ] 遮蔽凭据、验证码和完整验证链接，再保存日志或测试报告。
若本次验收需要验证外部收件，可以先查看 Inboxtick 临时收件箱的实际页面能力，再判断它是否适合自家产品的受控测试；临时地址适合短期试收，不适合银行、支付、政务等需要长期找回的账户，也不适合需要持续回信或长期收信的流程。使用前还可阅读邮件与临时地址的数据处理说明，确认测试资料的保留与删除边界。
常见问题
Spring Boot 4.2.0-RC2 邮件测试应放在哪个环境？
放在与生产隔离的开发或预发环境，并显式检查当前激活的 profile、邮件服务器地址和凭据来源。测试收件目标也应专门识别，避免测试代码或配置误把邮件发给真实用户。候选版本测试通过后，仍需在稳定版本和目标部署环境分别复核。
Spring Boot 测试通过了，怎么确认测试收件箱实际收到邮件？
应用测试断言只能证明被断言的逻辑运行，例如业务流程触发了发送调用；它本身不能读取外部收件箱。要确认实际收信，需要使用受控地址检查收件端是否出现对应邮件，再比对运行标记、收件人、主题和关键内容，并单独记录这一收件证据。
JavaMailSender 调用成功就代表邮件已送达吗？
不代表。JavaMailSender 的调用结果应结合实际配置和发送链路解释；即使邮件服务器接受了消息，也不能据此断言目标收件箱已经展示邮件。验收记录应分别写明应用是否调用发送路径、发送端可观察到的结果，以及受控收件端是否实际收到。
Spring Boot 4.2.0-RC2 邮件测试能替代稳定版回归吗？
不能。RC2 的测试结论只适用于本次候选构建、测试配置和被覆盖的流程，不自动适用于后续候选构建、稳定版或生产部署。若升级计划继续推进，应在稳定版发布或实际升级后，另行运行关键邮件流程并核对受控收件结果。