Mailpit vs MailHog：本地 SMTP 邮件测试工具哪个更适合？

详细比较

它们捕获开发邮件而不是经营邮箱

Mailpit 与 MailHog 让应用把测试邮件交给本地或开发网络中的 SMTP 捕获服务，再通过网页或 API 查看。它们适合检查密码重置、注册通知、订单模板和定时消息，不是面向真实用户的完整生产 SMTP 服务。SMTP 接收成功说明邮件进入捕获工具，不代表外部收件箱已经收到。尤其在复制生产数据库的测试站，捕获路径可以帮助避免误发真实通知，但必须实际确认应用所有发信入口都经过它，不能只修改一个表单设置就认为全部邮件被隔离。

功能依据：mailpit.axllent.org 官方说明；适用场景为编辑分析。

新项目与旧集成的判断不同

Mailpit 当前官方文档覆盖现代界面、搜索、API 与多种检查功能，官方 GitHub 发布记录也显示持续更新。MailHog 的最近公开正式版本仍为 v1.0.1，发行记录较旧，这提示新项目应关注维护成本，但不能仅凭版本年龄推断现有环境一定故障。若团队已经有成熟 MailHog API 测试，直接替换可能需要改断言和配置。合理判断是新项目优先评估 Mailpit，旧项目先核对依赖与兼容再迁移，不把维护活跃度简单转换成未经测试的可靠性分数。

功能依据：github.com 官方说明；适用场景为编辑分析。

邮件预览要覆盖多个组成部分

Mailpit 可以查看格式化 HTML、文本、头部、原始来源和 MIME 附件，提供搜索及其他开发检查入口。MailHog 也能通过网页查看捕获内容，具体体验应使用现有模板验证。应用测试不能只看到标题正确，还要检查文字版本、链接、字符编码、附件和发件身份。中文通知尤其需要观察换行、长产品名和小屏布局。两者都不是每一种邮件客户端的真实渲染引擎，浏览器中的漂亮预览不能证明 Outlook、手机邮件或外部网关显示相同。

功能依据：mailpit.axllent.org 官方说明；适用场景为编辑分析。

搜索与隔离让多人测试更清楚

多人或自动化同时向同一捕获服务发信时，收件箱可能混入不属于当前测试的消息。Mailpit 官方提供搜索与标签等工具，能够辅助按收件人、标题或其他条件定位；MailHog 的既有查询能力也应按所用版本核对。测试最好使用唯一的演示地址或任务标识，等待目标邮件出现，而不是读取列表第一封。这样可以降低并行测试误判，避免测试成功只是碰巧发现上一轮邮件。清理策略也要明确，不应一个任务清空其他人的捕获结果。

功能依据：mailpit.axllent.org 官方说明；适用场景为编辑分析。

API自动化要验证语义差异

Mailpit 的 REST API 支持自动化集成测试；MailHog 也提供 API，但接口路径、分页、响应结构与消息标识不能默认互换。迁移应检查查询、读取正文、附件与删除动作的实际返回，更新测试断言。测试要允许应用异步发送的合理等待，并在超时后报告没有收到，而不是无限轮询。消息出现只验证发信链路的一段，邮件中的重置链接和业务动作还需要独立检查。不要把 SMTP 协议兼容当成所有上层 API 兼容。

功能依据：mailpit.axllent.org 官方说明；适用场景为编辑分析。

Docker与本地应用接入不同

Mailpit 可以使用单个二进制或官方多架构 Docker 镜像，MailHog 也有相应运行与容器方式；镜像来源、标签和更新需要单独核对。容器内应用连接捕获服务时，应使用开发网络中的服务地址，不能把宿主机的 localhost 当作容器外的另一个服务。本地 PHP 应用则应使用它实际可以访问的地址和端口。出现无邮件时，先区分连接失败、应用没有发送和查询错误，避免改生产 SMTP 来“试一下”。配置可以共享方法，不能共享真实凭据。

功能依据：github.com 官方说明；适用场景为编辑分析。

WordPress需检查所有发信入口

WordPress 的 wp_mail、SMTP 插件、计划任务和某些第三方接口可能采用不同路径。把开发 SMTP 指向捕获工具后，先发一封演示通知，再检查注册、重置与业务邮件是否也进入同一环境。某些服务直接调用外部邮件 API，不会自动经过本地 SMTP，这类入口需要单独测试隔离。捕获工具中没有邮件，也不能直接推断 WordPress 没有发信，因为请求可能失败或经过另一服务。应查看不含秘密的错误信息和目标配置，确认实际路径后再修改。

HTML检查与垃圾检测的范围

Mailpit 官方列出 HTML、链接和垃圾邮件检查等功能，其中部分检查依赖外部服务或配置，例如垃圾检测需要相应 SpamAssassin 环境。它们可帮助发现模板与内容问题，却不能预测所有真实收件系统的规则，也不提供保证到达收件箱的分数。链接检查还可能向外部地址发送请求，测试邮件中的私密链接应谨慎处理。选择工具时应明确需要哪些检查、数据会流向哪里，以及在离线开发环境中哪些功能仍可使用。

功能依据：mailpit.axllent.org 官方说明；适用场景为编辑分析。

释放与转发应默认有明确边界

Mailpit 提供可选邮件释放或转发能力，MailHog 也有消息释放相关功能。开发捕获工具一旦接上真实外发 SMTP，就可能把演示邮件发送给实际地址。团队应区分只捕获的环境和允许外发的测试，限制收件人范围并保护外发凭据。不能为了验证模板而把整份生产通知队列释放出去。新项目可以先保持只捕获，确有投递测试需要时再建立受控目标。开发便利与真实外发是不同权限，必须让操作者能清楚识别当前状态。

运行安全与资料保留也要规划

邮件内容可能包含测试链接、个人资料或开发秘密，所以网页界面和 SMTP 端口应限制在需要的网络范围；远程共享时还应考虑认证与 HTTPS。邮件保留时间、数量和磁盘空间需要约束，避免长期累积完整测试数据。即使使用虚构用户，重置链接也可能赋予测试账户权限。容器日志和导出的原始邮件同样应谨慎保存。工具是否支持认证只是起点，实际是否启用、谁能够访问和什么时候清理，才决定测试环境的暴露范围。

以一封真实模板完成迁移验证

用虚构地址发送一封带中文标题、文字版本、HTML、链接和附件的通知，分别检查捕获、查询与预览。随后测试异步发送、重复任务和失败超时，确认断言不会误读上一封消息。新项目若这些动作在 Mailpit 中较容易实现，便有实际采用理由；旧 MailHog 项目则应先确认替换带来的收益超过 API 修改与维护成本。把配置、镜像版本和接管方法写进开发文档，让其他人能够复现，而不是只由一个开发者知道怎样打开收件箱。

生产邮件需要另一套验收

上线后还要使用受控地址验证邮件服务连接、发件域名认证、退信、限流与实际收件箱状态。开发捕获可以确认模板和应用触发条件，却没有经过生产提供商和接收方的全部链路。两种测试应互相补充，不能互相替代。对于登录和重置通知，应确认链接域名、有效期和身份操作正确；对于业务邮件，应确认重复发送和失败补偿有明确规则。这样才能把“工具收到邮件”转化为可解释的测试证据，而不是把它当作最终投递成功。