两个号变一个号：vibe 项目的账号合并实战指南

先说清楚：本篇提到的产品名、人物名、金额和对话，全部是为讲清楚方法而编的虚构示例，不是真实产品、不是真实用户案例。方法本身是通用的，流程里的具体天数和金额是举例用的标尺，不是任何产品的真实规则。

账号合并是 vibe 项目里最容易被低估的功能：它看起来只是“把两个号变成一个号”，做起来却牵扯订阅、余额、内容、协作权限、第三方绑定和审计记录，任何一处合错，用户损失的都是真金白银或者多年积累的内容。更麻烦的是，合并一旦做错几乎无法“反悔”——内容已经归到一个号名下，再拆回去往往只能靠人工对账。所以这篇指南不讲合并按钮长什么样，讲的是合并之前必须想清楚的判断、必须核验的权属、必须按顺序执行的步骤，以及做错时怎么兜底。

一、先分清：合并不是改绑、不是注销、不是换登录方式

动手之前，先把四个容易混淆的操作分开。改绑是同一个账号换一个登录凭证，比如把登录邮箱从 A 换成 B，账号本身没变，内容、订阅、权限原地不动。注销是把账号连同数据一起清掉，通常不可逆，合并绝不能用注销来实现“去掉一个号”。换登录方式是给同一个账号加一个新入口，比如原来邮箱登录、后来加了微信登录，账号还是同一个。而合并，是把两个已经各自产生数据的独立账号，变成一个账号，并且把两个号的数据、权益和关系按规则归到一起。

虚构示例：陈默在协作产品“白鹭协作”里有两个号，一个是工作邮箱注册的，里面有公司项目的文档和付费订阅；另一个是微信登录的，里面有他个人用的看板和几位朋友的协作空间。某天他想“统一成一个号”，客服如果直接按“改绑”处理，只会把其中一个号的登录方式改掉，另一个号的数据还在原地，他以为合完了，其实两个号都还在。合并的第一步，永远是先确认用户要的到底是哪一种操作，并且把“合并后被吸收的那个号会发生什么”白纸黑字告诉他：是被注销、被冻结，还是保留为只读存档。

这个区分之所以重要，是因为四种操作的不可逆程度完全不同。改绑做错了可以再改回来，合并做错了要拆数据，注销做错了可能什么都回不来。凡是涉及合并的入口，文案上必须出现“合并”两个字，不许用“关联”“同步”“绑定”这类含糊词代替。用户点错入口的成本，远高于多写两行说明的成本。

二、该不该做：先判断，再谈流程

不是所有“有两个号”的情况都应该合并。应该合并的典型情况有三种：第一，两个号确实属于同一个人，产生的原因是注册入口不同，比如先邮箱注册、后微信登录，系统没有认出是同一个人；第二，用户明确要统一身份，比如离职后想把工作号的内容带到个人号，或者反过来；第三，其中一个号基本是空号，合并只是为了清掉重复身份、避免以后登录时选错号。

不应该合并的情况同样明确。第一，两个号属于不同的人，哪怕是夫妻、合伙人、上下级，也不能合并——合并会把 A 的私人内容暴露给 B，事后无法用技术手段“假装没看见”。第二，其中一个号涉及纠纷，比如欠费、被投诉、处于封禁申诉期，合并会把纠纷带进另一个号，先解决纠纷再谈合并。第三，用户只是“登录不方便”，比如忘了某个号的密码——这种情况走找回流程，而不是合并。把“找回”做成“合并”，等于用不可逆操作解决一个可逆问题。

判断的责任不在用户，而在产品。合并入口的第一屏，应该是三道判断题而不是一个确认按钮：这两个号都是你本人的吗？两个号里有没有不属于你的内容或协作关系？被吸收的号里有没有正在生效的订阅、余额或待处理事项？任何一道答不上来，流程就应该停下来，转人工核对，而不是让用户“先点了再说”。

三、权属核验：证明两个号都是你，缺一不可

合并最危险的攻击面，就是有人冒充用户把别人的号“合”进自己手里。所以权属核验必须对两个号分别做，而且强度不能低于改密、换绑这类敏感操作。邮箱号要验证邮箱所有权，手机号要验证短信码，第三方登录要重新走一次授权确认。只验证其中一个号、另一个号靠“用户说是我”就放行，等于给账号盗取留了一个合法通道。

核验还要防一种常见漏洞：会话劫持。用户当前登录的号是 A，想把 B 合进来，系统必须要求用户在同一个流程里重新证明对 B 的控制权，而不是只凭“当前登录态是 A”就默认 B 也是他的。具体做法是：合并流程单独建一个短时有效的核验会话，两个号的凭证都在这个会话里重新校验一遍，校验通过才进入下一步。任何一步凭证过期，整个流程回到起点，不许“半核验、半放行”。

核验通过后，还要留一笔独立的审计记录：什么时间、哪个操作者、哪两个账号、通过了哪几种核验方式。这笔记录不属于任何一个号的普通操作日志，而是合并事件本身的档案。日后用户质疑“我没合过”，或者客服需要还原现场，靠的就是这笔记录。没有审计记录的合并，等于没有做过合并——出了问题谁也说不清。

四、冲突矩阵：合并前先把每一类数据摆上台面

合并真正的工作量在冲突处理，而不是在按钮逻辑。动手之前，先把两边账号的数据按类别列成一张冲突矩阵，逐类定规则，而不是等到代码里遇到再临场决定。常见的类别有七种，每一种都要有明确答案。

第一是身份类：用户名、头像、个人简介。两个号都有用户名时，保留哪一个？被吸收号的用户名是释放掉、保留一段时间，还是永久冻结防止冒充？务实的规则是：保留主账号的用户名，被吸收号的用户名冻结一段保护期，比如九十天内不许他人注册，期满后再释放。这个保护期不是摆设，它防的是有人立刻抢注旧用户名、冒充原主继续收消息。

第二是订阅与余额类：付费订阅、剩余天数、账户余额、优惠券。两个号都有订阅时，是叠加时长、取较晚到期日，还是按比例折算？余额能不能合并、有没有上限、优惠券会不会因为合并而失效？这些规则必须在合并前展示给用户确认，而不是合并后让用户在账单里自己发现。凡是涉及钱的规则，展示时要带上具体数字：合并后订阅到期日是哪天、余额是多少，数字对不上就不许点确认。

第三是内容类：文档、看板、文件、收藏。内容合并通常是“全部归到主账号名下”，但要处理重名、配额和所有权：两个号里各有一篇同名文档，是并存、改名，还是提示用户先手动处理？主账号的存储配额够不够装下两个号的内容？内容里的评论、点赞、版本历史，归属要不要跟着变？原则是：内容可以迁移，但历史归属信息不要重写——谁写的评论，合并后还是谁写的，改写历史会毁掉协作信任。

第四是协作关系类：团队成员身份、共享空间权限、外部协作者。一个人以两个身份加入同一个团队时，合并后应该只剩一个身份，而且权限取两者中较高者还是较低者，要提前定好。取较高者可能越权，取较低者可能丢权限，两种选择都有代价，关键是选之前告诉用户、并给出合并后的权限预览。预览里要列出每个团队、每个空间合并后的身份，逐项可核对。

第五是第三方绑定类：微信、GitHub、Google 这类外部登录，以及 API 密钥、授权应用。外部绑定通常不能“自动转移”，因为外部平台认的是那个具体的授权关系。务实的做法是：合并后主账号保留自己的绑定，被吸收号的绑定逐项提示用户重新授权或解绑，而不是静默迁移。API 密钥更要小心：被吸收号的密钥合并后是失效还是继续有效，必须明确，含糊处理等于留了一个没人管的后门。

第六是通知与偏好类：邮件订阅、通知开关、语言时区。两边偏好不一致时，以主账号为准是最简单的规则，但要告诉用户“被吸收号的偏好将被丢弃”，而不是悄悄覆盖。第七是待处理事项类：未完成的订单、待审核的内容、进行中的申诉。这类事项合并前必须先结清或明确归属，带着未结事项合并，等于把一团乱麻从两个号打成一个结。

五、执行顺序：先冻结、再迁移、最后收尾

冲突规则定好之后，执行顺序决定合并会不会中途翻车。推荐的顺序是五步。第一步，冻结两个号：合并期间两个号都不许再产生新数据、不许改密码、不许新购订阅，否则迁移到一半又冒出新数据，永远对不上账。冻结要给用户明确提示和预计时长，而不是悄悄锁号让用户以为被封了。

第二步，做合并前快照：把两个号的关键数据做一份可恢复的备份，至少包括身份、订阅、余额和内容清单。快照不是为了“随时反悔”，而是为了合并失败时能回到合并前的状态。没有快照的合并，失败后只能靠人工翻日志拼数据，成本极高。

第三步，按冲突矩阵迁移数据，顺序是身份先定、内容次之、钱最后。先把主账号身份定下来，再迁内容和协作关系，最后处理订阅和余额——钱放在最后，是因为钱的规则最容易在前面步骤出错时被连带污染。迁移过程要分批、可断点续跑，每批完成后校验数量对得上再跑下一批，而不是一次全量提交、错了全盘重来。

第四步，校验与用户确认：把合并结果清单展示给用户，包括订阅到期日、余额、内容数量、团队身份，逐项对得上才算完成。第五步，收尾被吸收号：按第一步告知用户的方式处理，注销、冻结或只读存档，并且把旧登录入口的指向处理干净——用户下次用旧方式登录时，应该看到“该账号已合并到某某账号”的明确提示，而不是“账号不存在”这种让人恐慌的报错。

六、失败与回滚：合并功能必须先写好“拆回去”的能力

合并功能上线前，先问自己一个问题：如果迁移到第三步断电了、数据库写了一半，系统能不能回到合并前的状态？答不上来，这个功能就不该上线。回滚能力不是事后补丁，而是合并功能的一部分：每批迁移都要有对应的逆操作，或者整个迁移包在一个事务里完成，失败则整体回滚。所谓“先上线、失败了人工处理”，在涉及钱和内容时是不可接受的。

回滚还要分两种：技术回滚和用户反悔。技术回滚指迁移本身失败，系统自动回到快照状态，并通知用户“合并未完成、两个号原样不动”。用户反悔指合并成功了、用户又想要回去——这种情况原则上不提供“一键拆分”，因为拆分的数据归属比合并更难界定；但要提供人工申诉通道，并且在合并前用冷静期兜底：比如合并完成后七天内，被吸收号的数据仍保留在快照里可恢复，七天后才真正清理。冷静期的存在，会让用户在点确认时更敢点，也让客服在纠纷时有据可查。

失败时的用户体验同样重要。合并失败的提示不能只写“操作失败，请重试”，要写清楚失败在第几步、两个号现在是什么状态、用户接下来该做什么。最怕的是失败后两个号处于“半合并”状态：内容过去了、订阅没过去，用户两边都查不到完整账。凡是可能出现半合并状态的设计，都要在上线前用故障演练跑一遍，而不是等真实用户撞上。

七、上线检查表与反模式

上线前逐项打勾：合并、改绑、注销、换登录方式四种入口文案互不混淆；合并首屏有三道判断题；两个号分别完成权属核验、核验会话短时有效；冲突矩阵七类数据逐类有规则、涉及钱的规则带具体数字展示；被吸收号用户名有保护期；合并前快照已做、迁移分批可断点续跑；钱类迁移放在最后；合并结果清单经用户确认；旧登录入口有明确的合并指向提示；失败可回滚到快照、半合并状态有演练；合并事件有独立审计记录；冷静期与人工申诉通道已就位。

八、给客服的交接：合并工单应该长什么样

再好的自助合并流程，也会有用户走到人工客服面前。客服拿到合并工单时，第一眼应该看到四样东西：两个账号的标识与核验结果、冲突矩阵里每一类的处理结果、合并前快照的位置、冷静期还剩几天。工单里缺任何一样，客服就只能凭感觉回复，而感觉回复最容易在钱和权限上说错话。工单模板要在功能上线前就定好，不要等第一单纠纷来了才现写。

反模式清单，出现任何一条都要回炉：只验一个号就放行合并；用“关联”“绑定”代替“合并”文案；钱类规则合并后才让用户在账单里发现；用户名立刻释放给他人注册；第三方绑定静默迁移；API 密钥归属含糊不清；合并期间不冻结、任由新数据冒出来；没有快照、失败靠人工拼数据；失败提示只写“请重试”；合并后旧登录入口报“账号不存在”。账号合并做得好，用户只会觉得“终于统一了”；做得差，用户失去的是订阅、内容和信任——而信任丢了，是合不回去的。