迁移第二个网站的客户时，CSV 里邮箱在目标 Website 从未出现，导入仍提示重复。有人准备给邮箱末尾加后缀先导进去，这会破坏登录、通知和历史订单关联，通常不是可接受的修复。

先确认客户账号共享范围

Magento 可以按 Global 或 Per Website 共享客户账号。Global 模式下，同一个邮箱全站只能有一个客户；Per Website 模式下，同邮箱可以在不同 website_id 存在。先核对当前配置，再查询实际数据：

SELECT entity_id, email, website_id, store_id, created_at
FROM customer_entity
WHERE email = :email
ORDER BY website_id;

不要用 Store View 名称代替 website_id。store_id 决定客户创建时的商店上下文，唯一性核心通常是 email 与 website 范围。CSV 中 Website 字段映射错误，会把所有客户导进默认网站，于是产生“意外重复”。

改变共享范围不是无成本开关

从 Per Website 改成 Global 前，必须先扫描跨网站同邮箱客户，因为合并后会发生身份冲突。两个账号可能有不同密码、地址、客户组、订阅状态和订单历史，不能自动认定它们是同一个人。

反过来，从 Global 改成 Per Website 后，也要决定现有客户属于哪些网站，以及登录、重置密码和 SSO 的预期。配置改变应在迁移方案里明确，而不是为了让一次导入通过临时切换。

导入文件还要处理大小写和空白

邮箱前后空格、不可见字符、大小写规范化和字符编码会导致肉眼看似不同、系统判断冲突。导入前用脚本做规范化并生成重复报告，但保留原始文件以便审计。不要把“去重”写成简单保留最后一行，客户资料可能在其他行更完整。

冲突客户要有业务决策

同一自然人在两个网站有账户，可以选择账号合并、保留网站隔离，或建立明确关联。合并时需要迁移地址、订单可见性、订阅与客户组，并通知用户密码策略。无法自动判断的冲突进入人工清单。

最终用三种账号测试：只在网站 A、只在网站 B、两个网站同邮箱。验证登录、忘记密码、下单和后台查找都符合共享策略。导入“成功”只是技术结果，客户能在正确网站继续使用账号才是业务完成。