跨主体换小程序，会员身份为什么带不走？

会员表导出来了，积分也在。老板把小程序从 A 公司迁到 B 公司，或者从旧服务商换到新服务商，数据一条不少。上线第一天，老会员打开新小程序，登录，看到一个空白账号；客服开始收到同一句话：“我的积分呢？”

问题通常不在数据，而在身份。你搬走了记录，但新小程序未必知道这条记录对应哪一个微信用户。

境外主体小程序尤其如此：手机号快速验证组件大多没有开放，会员表里也常常没有可用的手机号。身份匹配不能假设有手机号，必须从别的标识开始设计。

很多迁移方案把这件事简化成“把 OpenID 导过去”。在微信的体系里，这句话几乎一定会出问题。

一、AppID、OpenID、UnionID，先分清

AppID 标识的是小程序这个账号，不是用户。OpenID 标识的是“某个微信用户 + 某个小程序”的组合；同一个用户打开两个小程序，会得到两个不同的 OpenID。微信的术语说明写得很直接：同一用户在不同小程序里的 OpenID 不同。

UnionID 解决的是跨应用问题，但只在同一个微信开放平台账号下成立。如果两个小程序都绑定在商家自己的开放平台账号下，同一个用户才可能共享 UnionID。这里有两个前提：绑定关系在商家自己的账号下，而且平台规则允许。

这也解释了一个常见误会：服务商代开发的小程序，不等于服务商能替商家把所有用户身份打通。身份打通发生在商家自己的开放平台账号里，不在服务商的第三方平台账号里。服务商可以代开发和代运营，但不能替代商家成为身份的归属方。

二、境外主体不能做账号迁移，跨主体只能新建小程序

先纠正一个常见误解：微信的“小程序账号迁移”和“小程序主体变更”是两件事。账号迁移跨两个账号、AppID 会变，旧小程序会被注销；主体变更在同一个账号内、AppID 不变。而账号迁移的准入条件明确写着“海外主体账号暂不支持准入”。也就是说，境外主体的小程序不能通过平台能力把账号和用户转给另一个主体。

不同主体之间因此没有平台级迁移通道：新主体只能注册一个新的小程序（新 AppID），旧小程序不会被自动注销或跳转，会员也不会自动跟过去。能做的，是在新小程序里重新建立会员身份，再把权益迁过去。

• 同一主体内换服务商、重做小程序。通常是新 AppID；OpenID 必然不同，UnionID 只有在两个小程序绑定同一个开放平台账号时才可能延续。
• 不同主体之间。没有账号迁移；新小程序属于新的命名空间，旧 ID 不可用，只能靠用户主动关联、自有会员标识或已验证属性。
• 换平台。从微信小程序换到 LINE、其他 SaaS 或自建 App，命名空间完全变了，旧 ID 在新系统里没有意义，只能靠用户主动关联或已验证属性匹配。

把场景写进方案第一页，比在导入脚本里猜 ID 有用得多。跨主体迁移前 30 天的通知与认领安排，见旧小程序关停前的 30 天。

三、手机号不是万能钥匙，境外主体大多拿不到

先确认你能不能拿到手机号。微信的手机号快速验证组件并非对所有小程序开放：境内主体一般可以接入；境外主体从 2024 年起只对部分国家/地区的已认证主体灰度开放，公告列出的范围包括中国香港、中国澳门、中国台湾、日本、韩国、新加坡、马来西亚、泰国、越南、柬埔寨、缅甸、印度尼西亚、老挝、菲律宾、新西兰、澳大利亚、阿联酋。不在名单里的境外主体拿不到手机号；即使在名单内，也仍属于灰度能力，接入前要以官方最新公告为准。对大多数境外主体小程序来说，实际答案就是拿不到。

所以做境外小程序迁移，默认假设应该是“没有手机号”。这时能依赖的是同一开放平台账号下的 UnionID、用户主动关联、自有会员卡号，或已验证邮箱。不要把一个拿不到的字段写进迁移方案，也不要等到上线后才发现会员表里没有手机号。

能拿到手机号，也不等于可以直接用：历史会员表里未必有手机号，有手机号也未必验证过；用户会换号，一个号码可能对应多个家庭成员，同一个人可能有多个账号，海外号码格式还不统一，早期数据可能是客服手工录入的。这些都会让“手机号相同”变成一条线索，而不是一个结论。

所以手机号可以用，但要带着前提和规则用：先确认主体与地区是否开放；只匹配已验证号码；保留冲突记录；同号多账号时不自动合并；匹配结果让用户能确认或申诉。对境外主体，先按“没有手机号”做方案，再考虑手机号能不能作为加分项。

四、可行的匹配顺序

从强到弱，建议按这个顺序设计：

1. 用户主动关联。用户在新小程序登录后，用旧手机号收验证码、登录旧系统，或完成一次明确授权。速度慢，但这是跨主体、跨平台时最可靠的办法。
2. 同一开放平台账号下的 UnionID。关系强，但依赖账号结构和绑定关系；主体变更后要先验证。
3. 已验证手机号或邮箱。能拿到时适合作为主要匹配键，但必须处理换号、共用、重复账号和格式差异；境外主体先确认手机号组件是否开放。
4. 商家自有的会员卡号、订单号。用户能证明“这是我的”时可用；不能只凭卡号就把余额并过去。
5. 模糊匹配。姓名、地址、消费记录只能用来缩小人工复核范围，不能自动合并，更不能自动转移储值。

昵称、头像、地区不建议作为匹配依据：它们既不稳定，也不唯一。

五、合规和沟通，不是技术收尾

身份匹配做完，只解决了“能不能认出”。接下来还要回答“能不能这样用”。迁移前至少确认：向用户告知了什么；迁移的目的是什么；新旧系统分别由谁持有数据；保留多久；用户如何查询、更正或删除；储值、预付卡和未履约权益由谁承接。

这些问题的答案通常不在技术方案里，而在法务、财务和客服流程里。适用法律可能要求告知、同意和最小必要；具体义务请以法务意见为准。不要等到上线当天才让客服解释“为什么我的余额不见了”。

六、上线前的最小验证

不用先做完整迁移，取 100–500 条有代表性的记录（包含没有手机号、换过号、重复账号的），把下面几件事跑一遍：

1. 统计可用标识：有多少条有已验证手机号、UnionID、自有会员卡号，或者什么都没有。
2. 确认真实字段：新系统接受哪个字段、什么格式、是否唯一、冲突时怎么报错。
3. 模拟用户到达：用测试账号登录新小程序，看系统能否找到导入记录，会不会创建重复账号。
4. 给样本分类：精确、可能、未匹配、冲突各多少；每一类抽几条人工复核。
5. 准备兜底：未匹配用户去哪里认领？多久处理？谁负责？储值暂时冻结还是人工补发？

如果这 100–500 条都分不清楚，生产迁移的工期和报价就没有依据。

七、回到最开始的问题

不是“会员表能不能导出”，而是“新小程序能不能认出这个人”。如果答案依赖旧小程序里的 OpenID，迁移就还没准备好；如果依赖用户重新授权、同开放平台账号下的 UnionID，或已验证手机号（前提是手机号组件对你开放），你至少有东西可以测试，也能据此划定范围、报价和承诺。

AcrossFlow 正在和面临这类转换的商家一起验证流程。如果你正准备换主体、换服务商或换平台，先从身份盘点开始。