一、为什么统一账号体系是难点
一套商城系统通常同时提供微信小程序、支付宝小程序、抖音小程序、APP、H5 多端入口。同一个用户，可能在微信小程序下单、在 APP 里看积分、在 H5 上参与分销。如果每个端各自建一套账号，就会出现一个用户被拆成多个身份、订单和积分互相看不到的乱象。
统一账号体系要解决三件事：同一用户多端可登录、登录后身份唯一、历史数据（订单、积分、分销关系）不丢。
二、账号模型设计：用户与凭证分离
核心原则：业务主体是「用户」，登录凭证是「账号」，两者分离。一个用户可绑定多个账号（微信、支付宝、抖音、手机号），一个账号只能属于一个用户。
| 表 | 关键设计 |
|---|---|
| 用户表 | user_id 为主键，承载昵称、头像、手机号（冗余字段，便于查询）、会员等级、状态；订单、积分、分销关系都挂在 user_id 上 |
| 账号表 | account_id 为主键，包含 user_id、账号类型（手机号 / 微信小程序 / 微信公众号 / 微信 APP / 支付宝 / 抖音 / Apple）、账号标识（openid 或手机号）、unionid、绑定状态、绑定时间；同一账号类型 + 账号标识唯一 |
| 会话表 / 令牌 | 记录登录态：token、user_id、来源端、有效期、最后活跃时间；支持主动失效（改密、注销、风控） |
这样设计的好处：新增一个端（比如上抖音小程序）只需要新增账号类型，不动业务表；订单、积分始终以 user_id 关联，天然统一。
三、多端登录流程设计
以微信小程序为例的通用流程：
-
客户端调用 wx.login 获取临时 code，连同端标识发给后端。
-
后端调用微信 code2session 接口，换取 openid 与 unionid。
-
用 unionid（已绑定开放平台时）或 openid 在账号表查找：命中则直接登录；未命中则创建用户与账号，完成首次登录。
-
签发会话令牌返回客户端，后续请求携带令牌鉴权。
手机号登录：校验验证码后，以手机号作为账号标识走同一套「查账号 / 建账号」逻辑。支付宝、抖音小程序、APP 的微信登录、H5 的公众号授权，都复用同一条路径，差异只在换取第三方凭证的方式。
四、UnionID 与 OpenID 怎么选
OpenID 是同一用户在单个应用内的唯一标识，不同应用（小程序 A、小程序 B、公众号）之间不通用。UnionID 是同一用户在同一微信开放平台账号下的唯一标识，可跨小程序、公众号、APP 识别同一用户。
多端商城必须依赖 UnionID 打通微信生态内的多个入口；同时建议保留 openid 作为单端凭证，两者都存，查询用 openid，识别同一用户用 unionid。支付宝、抖音等平台也各有开放平台标识体系，设计上统一收口到「账号类型 + 账号标识」即可。
五、账号绑定与合并策略
最常见的场景：用户先用微信登录产生账号 A（有订单、积分、分销关系），后来用同一手机号注册了账号 B。此时需要合并而非简单覆盖。
推荐策略：
-
手机号验证通过后，优先尝试自动绑定：若手机号已绑定其他账号，不直接合并，先提示用户确认，防止恶意接管
-
合并时以「保留时间更久 / 资产更多」的账号为主账号，另一账号的订单、积分、优惠券、分销关系迁移到主账号，并注销被合并账号的登录凭证
-
合并动作在事务内完成，配合异步任务做资产明细迁移，迁移过程对用户可见（进度或结果通知）
-
同一手机号换绑、解绑需二次验证，变更记录留痕
六、会话安全与多端体验
令牌建议用短期令牌 + 刷新令牌双层结构，降低泄露风险；修改密码、注销、风控触发时主动吊销全部会话；不同端允许同时在线（手机端 + 小程序端），同一端异常登录可提示用户。
七、踩坑清单
-
UnionID 需要小程序与公众号绑定同一微信开放平台账号才能拿到，未绑定时只有 openid，容易在联调阶段卡住
-
微信手机号快捷授权需要企业认证主体，个人主体无法调用
-
小程序卸载重装后 openid 不变，但用户可能误以为「换了个账号」，需在客服 / 帮助中心说明
-
账号注销涉及订单、积分、分销资产的合规处理，需在用户协议中明确规则
-
隐私合规：收集手机号、头像、位置等信息需有用户协议与隐私政策，并支持撤回授权
八、总结
统一账号体系是商城系统的地基。把「用户」与「凭证」分离、用 unionid 打通多端、用明确的绑定合并策略保住历史资产，才能在业务扩张（新增端、新增入口）时不返工。建议新项目在立项阶段就把账号模型定下来，避免后期拆表重构。
（文末）本文方案是慧米云多年多端商城开发中的通用工程实践沉淀