顾客忘记自己注册过账号，直接以访客身份下单，结账页却提示 A customer with the same email address already exists。这个提示有时是安全设计，有时是扩展把“检查邮箱是否存在”误当成“禁止结账”。能不能继续下单，取决于站点的访客结账策略和本次流程是否创建客户实体。

先确认配置目标

在 Stores → Configuration → Sales → Checkout 检查 Allow Guest Checkout，并确认配置范围是当前 website/store view。标准访客订单可以使用与已有客户相同的邮箱，因为订单地址与客户账号不是同一实体；但强制登录、B2B 公司账号、订阅或支付风控扩展可能主动禁止。

看请求正在保存 quote 还是创建 customer

Network 中找到 payment-information、guest-carts 或自定义 register 请求。若堆栈进入 customer repository 的 save，并尝试创建新 customer，就要查主题里的“结账时创建账号”勾选项是否默认开启，或扩展是否无条件执行注册。

数据库只做只读确认：

SELECT entity_id, email, website_id, is_active
FROM customer_entity
WHERE email = 'customer@example.com';

同一邮箱在不同 website 是否允许复用，受客户账号共享范围影响。不要为让结账通过而直接改 customer email，这会破坏登录与订单归属。

邮箱存在性接口不能泄露账号信息

某些一页结账扩展在输入邮箱后立即显示“该邮箱已注册”。这会被用于枚举客户账号。更安全的交互是提示用户可以登录获得订单历史，同时仍按配置允许访客结账；需要强制登录时，也应使用统一文案与速率限制，而不是暴露明确的注册状态。

修复后验证订单归属

分别测试全新邮箱、已注册但未登录、登录客户三种情况。访客订单的 customer_is_guest 应为真且不应凭邮箱自动挂到客户账号；登录订单则必须保存 customer_id。支付成功后再确认邮件收件人、地址和后台订单客户类型。能进入成功页但错误关联客户，同样是严重的数据问题。

如果业务要求已有邮箱必须登录，还要验证密码重置、社交登录和多网站账号范围，避免客户被卡在无法完成的循环：结账要求登录，登录页却在错误 website 查不到账号。错误文案应告诉客户下一步，而不是只抛异常。修复后检查访客订单不会意外出现在同邮箱客户的账户历史中；需要合并订单时，应走明确、可审计并经过授权的业务流程。

最后检查支付快捷按钮。Apple Pay、PayPal 等快捷流程可能在标准邮箱组件之外创建 quote，若只修普通 Checkout，快捷支付仍可能触发同一冲突。把三类邮箱状态与所有启用的结账入口做成回归用例，才不会在主题升级后重新出现。