客户说买了东西却没收到邮件，先拿到订单号，再问清楚缺的是哪封通知：顾客的付款后通知，还是店主的新订单通知？它们的开关和收件地址不同，不能用店主收到一封邮件来证明顾客也收到了。
排查顺序是：订单有没有到该发信的状态，具体模板有没有启用、地址是否正确，Woo 有没有尝试发送，最后才查发信服务与收件箱。这样能分清“这次根本没发”和“发了但没送到”，也能发现付款出了问题、邮件只是跟着没发生的情况。
下面沿一笔蓝色 M 码 T 恤订单说明。订单号 733 和它的记录都是教学例子，并非本站客户订单。配图中的“支付与订单状态 → 模板和日志 → 服务商与收件箱”，对应的就是这个检查顺序。
打开这笔订单，先确认付款和状态
进入 WooCommerce → 订单，找到客户提供的订单号。核对商品、下单时间和账单邮箱，避免查到同名客户的另一单。记录支付方式、当前状态与订单备注；备注常能帮助你看出付款确认、状态变化和某些邮件尝试发生的时间。
本例中，订单 733 已有成功付款记录，状态是“处理中”，店主收到了新订单通知，但顾客没有收到相应的处理中邮件。先确定这些事实，我们才能继续查顾客模板。
如果你看到的是“待付款”，先去支付网关看这笔交易。客户打开结账页、创建了订单，并不等于已经付款。尚未付款时，通常不能期待收到已付款的订单通知；具体邮件仍按网关和当前模板的触发规则判断。
另一种情况是网关已经确认付款，Woo 却一直待付款。此时先查付款消息有没有传回网站，而不是急着换发信插件。把订单号、网关交易号、付款时间和订单备注交给负责支付插件的人。不要为发出邮件而手动改成“处理中”：这可能掩盖未更新的付款状态，还触发库存、仓库同步等动作。官方邮件排错说明也把这种情况与普通发信故障分开。
找到具体模板，再核开关和地址
打开 WooCommerce → 设置 → 邮件。这个页面列出不同通知，不是一个总开关。店主的新订单通知通常对应 New order；顾客付款后的处理中通知对应 Processing order。你要按这单状态和缺信对象选模板，自定义状态或邮件插件还可能增加自己的规则。
进入对应模板，检查是否启用。常见界面有 Manage（管理）；使用新的邮件编辑界面时可能通过 Actions → Edit 进入。WooCommerce 9.8 引入的邮件改进，以及后续编辑功能，会影响页面外观。以你站点显示的设置为准，关键是找到同一个通知的开关和收件规则。邮件设置官方文档说明了这些入口与差异。
顾客通知通常发往订单中的顾客邮箱。店主通知则有可配置的商家收件地址，必要时还可能有多个。订单 733 缺的是顾客邮件，因此先核订单中的账单邮箱有没有拼错；只改 New order 的店主收件人，解决不了这个问题。
预览或“发送测试邮件”可以检查外观、底层发送和测试地址，但不会重现这笔订单的付款状态变化。测试邮件能收到，也不能证明顾客的 Processing order 自动通知已正常触发。
在邮件日志里看，这次到底发生了什么
模板和地址看完后，进入 WooCommerce → 状态 → 日志，寻找来源 transactional-emails，即订单等业务通知的邮件记录。按下单或状态变化的时间查相关文件，再找同一订单号和邮件类型。
当前官方文档说明了四种结果。看到英文标签时，按它实际表示的动作往下查：
| 日志结果 | 这次发生了什么 | 接下来查什么 |
|---|---|---|
| Disabled | 对应通知被关闭，这次没有发送 | 找到同一个邮件模板，确认是否应该启用 |
| Skipped | 缺少发送所需条件，例如没有收件人 | 查该条记录的原因、订单地址或插件所需条件 |
| Failed | 系统尝试发送，但返回错误 | 让维护者核错误、SMTP 或主机邮件服务 |
| Sent | 系统成功把邮件交给邮件发送系统 | 查服务商接受、退信和收件箱，不能直接判客户收到 |
在教学订单 733 中，我们查到顾客 Processing order 的结果是 Disabled，再确认这个模板确实关闭了。原因已经找到：这一封通知没有被发出。此时安装另一款 SMTP 插件并不能使关闭的模板自动发送，应该先恢复这个模板的正确设置。
如果查不到记录，也不能立即写“Woo 没触发”。先确认站点版本是否支持当前文档中的日志功能，日志是否保留了那一天，以及 状态 → 日志 → Settings（设置） 的记录级别。Sent 属于 INFO，Disabled 和 Skipped 属于 NOTICE；设置只保存较严重错误时，这些记录可能看不到。没有权限或已经过期的日志，是缺少可判断的资料。
当前文档还说明，Sent 和 Failed 可写入订单的私有备注，而 Disabled 和 Skipped 只在日志里。因此订单备注没有发信信息，不足以证明所有邮件都没有尝试。扩展或自定义邮件也可能另有日志入口，交给对应插件维护者核查。
日志写 Sent，继续查服务商和实际邮箱
如果你的记录不是 Disabled，而是 Sent，问题就到了后半段：发信系统接下来做了什么？登录站点使用的邮件服务后台，按时间和目标地址找这次发送，查看是否接受、退信、被服务商抑制，或者因收件地址无效而失败。
没有邮件服务后台权限，就把订单号、邮件类型、发送时间和脱敏日志交给负责发信的人。不要把顾客完整邮箱、密码或 API 密钥贴到公开求助页面。维护者才能继续检查发件域名验证、发信配置和服务商返回结果。
接着让收件人检查垃圾箱、促销分类和邮箱过滤规则。服务商显示接受，只能说明它接收了发送请求；收件服务器接受，也还不等于客户在主收件箱看到这封信。最后用正确的订单号确认找到的是本次通知。
若同站的报价表单通知也不正常，可以继续查WordPress 表单邮件投递中的底层发送与实际收件问题。但订单邮件仍需先完成自己的付款状态与模板检查。
修复后用新订单验证，真实客户补发另处理
回到订单 733 的例子：启用正确顾客模板并保存，修好了设置。原先被关闭时跳过的通知，不应假定会自动补发。要证明以后的自动通知恢复，应在隔离测试站用自己的邮箱做一笔新测试单，使它正常进入同样的状态，再核对应日志和实际收件。安全做法见WooCommerce 上线前测试下单。
这次新单如果显示 Sent，且顾客测试邮箱实际收到同号、正确商品和金额的通知，才能说这一条自动通知已恢复。店主通知另查自己的模板和邮箱。若只是点击通用“测试邮件”成功，还没有检验订单状态触发通知的过程。
真实客户那一单的沟通要另处理。补发前，核实正确邮箱、已有发送记录、客户是否其实在垃圾箱找到，以及客服此前有没有发过。需要重发哪一种通知，就使用店铺支持的对应操作并记下次数。不要连续点重发，也不要随意改订单状态来制造通知。
一封补发邮件可以解决这位客户的信息缺失，却不能证明下一笔订单会自动发信。把“客户这单已补发”和“自动通知已复测”分别记清楚，避免下次又出现同样投诉。
如果你卡在模板、日志或邮件服务的衔接，可以把网站地址、缺的是哪种邮件，以及脱敏后的订单状态和日志发给跨境YOUNG，讨论网站维护的处理范围。客户退款、付款与沟通由店铺按自身流程决定。
常见问题
有订单但还在“待付款”，为什么没有顾客确认邮件？
先看该网关有没有确认付款，再判断现在应该触发哪种通知。未付款的订单通常不会发出你期待的已付款通知；网关已付款、Woo 仍待付款，则查网关通知和状态更新。不要只为让客户收到信就改成“处理中”。
SMTP 工具测试邮件能收到，为什么订单邮件仍没有？
测试工具通常没有走这笔订单的状态和模板。按订单号查付款、对应通知开关、收件地址和邮件日志。Disabled 或 Skipped 要先处理模板或缺少的条件；Sent 才继续查投递与收件。
能否直接点“重发”解决顾客投诉？
先核这封信是否已发、地址是否正确和客户是否已经找到。确实需要补发时，按客服流程使用对应通知操作并记录次数。补发不能修复付款状态或关闭的模板，自动机制仍要用受控新订单验证。