多端产品的登录体验一直是绕不开的工程问题。用户早上在Web端登录了账号，中午打开App又被要求输密码，晚上进了小程序还得再注册一次，这种体验会直接拉低产品口碑。要解决这个问题，核心思路是把身份认证从各个客户端中剥离出来，收敛到一套统一的账号体系，由认证中心统一签发和校验凭证。本文基于React技术栈，详细讲解Web、App与小程序三个端的账号打通方案。
一、统一登录的整体架构设计
多端打通的第一步是设计一个独立的认证中心。认证中心本质上是一组后端接口加上一套Token签发规则，它不关心请求来自哪个端，只关心凭证是否有效。所有端的登录请求最终都指向同一个认证服务，登录成功后返回统一的凭证格式，业务服务在网关层或接口层校验这个凭证。
具体到客户端层面，React Web应用、React Native构建的App、以及基于Taro或uni-app（React语法）开发的小程序，各自封装一个请求层，请求层负责在每次请求时附带Token、处理401状态码并触发刷新逻辑。这样业务代码完全无感知，登录态的管理被收敛到基础设施层。
需要强调的是，多端打通并不意味着所有端走完全相同的登录接口。Web和App可以直接走账号密码、手机验证码等标准流程，而小程序出于平台规范，首选wx.login获取code再换取openid的静默登录方式。所以架构上应该是统一凭证、差异化入口：入口各端不同，但最终拿到的Token格式和校验逻辑完全一致。
二、双Token机制的设计与实现
单Token方案最大的矛盾在于有效期设置：设得太短用户频繁掉线，设得太长一旦泄露风险窗口期过长。业界主流做法是双Token机制：短有效期的accessToken负责日常请求鉴权，长有效期的refreshToken负责在accessToken过期后换取新的凭证。
accessToken建议设置2小时左右的过期时间，存放在内存中（Web端）或安全存储中（App端）；refreshToken设置7到30天有效期，Web端存localStorage要考虑XSS风险，更稳妥的做法是让后端通过HttpOnly Cookie下发。下面是一个React端的Token管理模块示例：
// tokenManager.js
let accessToken = null;
let refreshToken = localStorage.getItem('refresh_token');
export function setTokens(access, refresh) {
accessToken = access; // accessToken 只存内存，刷新页面后丢失
if (refresh) {
refreshToken = refresh;
localStorage.setItem('refresh_token', refresh);
}
}
export function getAccessToken() {
return accessToken;
}
export function getRefreshToken() {
return refreshToken;
}
export function clearTokens() {
accessToken = null;
refreshToken = null;
localStorage.removeItem('refresh_token');
}这样做的好处显而易见：accessToken在内存中，XSS攻击很难偷走；refreshToken即使被偷走，也可以通过服务端的设备管理机制单独吊销。配合设备指纹，可以精确控制某一台设备下线而不影响其他端的登录态。
三、请求封装与无感刷新Token
三个端的请求层逻辑高度相似，核心是拦截器。以axios为例，请求拦截器负责注入Token，响应拦截器负责捕获401并触发刷新。刷新时要特别注意并发问题：页面加载时可能同时发出五个请求，accessToken同时过期，如果每个请求都去刷新一次，refreshToken很可能因为重复使用而被服务端判定异常并强制下线。
解决办法是用一个共享的刷新Promise，让并发的401请求都等待同一次刷新完成：
// request.js
import axios from 'axios';
import { getAccessToken, getRefreshToken, setTokens, clearTokens } from './tokenManager';
const instance = axios.create({ baseURL: 'https://api.ipipp.com' });
let refreshing = null; // 共享的刷新任务
instance.interceptors.request.use(config => {
const token = getAccessToken();
if (token) config.headers.Authorization = `Bearer ${token}`;
return config;
});
instance.interceptors.response.use(
res => res,
async err => {
const { response, config } = err;
if (response && response.status === 401 && !config._retried) {
config._retried = true;
try {
if (!refreshing) {
refreshing = axios.post('https://api.ipipp.com/auth/refresh', {
refreshToken: getRefreshToken()
});
}
const { data } = await refreshing;
refreshing = null;
setTokens(data.accessToken, data.refreshToken);
config.headers.Authorization = `Bearer ${data.accessToken}`;
return instance(config); // 用新 Token 重放原请求
} catch (e) {
refreshing = null;
clearTokens();
window.location.href = '/login';
}
}
return Promise.reject(err);
}
);
export default instance;小程序端的请求封装思路相同，只是API层从axios换成Taro.request或wx.request，存储从localStorage换成wx.setStorageSync。需要注意小程序没有Cookie机制，refreshToken只能存在本地缓存中，因此服务端需要对小程序端的refreshToken做更严格的设备绑定。
四、小程序登录的特殊处理与账号绑定
小程序登录的推荐流程是：前端调用wx.login拿到临时code，发送给自己的后端，后端拿着code、AppID和AppSecret请求微信的jscode2session接口，换取openid和session_key。openid是用户在当前小程序下的唯一标识，但它不等于你账号体系的用户ID。
这里的关键设计是账号绑定表：后端维护一张映射表，把openid、unionid与内部userId关联起来。用户首次通过小程序进入时，如果openid没有绑定记录，引导用户通过手机号快捷登录完成绑定；之后再次进入，凭openid直接静默登录，签发与Web端完全相同格式的Token。unionid的作用更大——如果同一个微信开放平台下还有App和公众号，unionid可以把这些渠道的身份也串联起来。
流程上还要考虑降级场景：用户在小程序里点授权手机号但拒绝，应提供验证码兜底；App端可以用极验、号码认证等一键登录方案，但最终都收敛到同一个账号绑定逻辑。
五、退出登录与多端状态同步
统一登录做到最后一定要处理退出同步。理想体验是用户在Web端点了退出，App端下次请求也自动下线。实现方式是服务端维护Token黑名单或者版本号机制：用户表里加一个tokenVersion字段，签发Token时把版本号写进载荷，校验时比对当前版本，退出登录时版本号加一，旧Token全部失效。如果只想让单一设备下线，就按设备粒度管理refreshToken，退出时吊销对应记录即可。
客户端层面，各端在收到401且刷新失败后，清理本地存储并跳转登录页。App端还可以结合推送，在用户主动退出时给其他设备下发踢出通知，进一步提升体验的一致性。至此，一个完整的统一账号体系就闭环了：入口差异化、凭证统一化、退出同步化，这正是多端账号打通的核心三要素。