Taro 多端客户端状态一致性：登录、收藏、主题与评论

本文根据一个个人 Taro 多端客户端的默认分支源码做静态复核。项目使用 Taro、React、Zustand 与统一请求模块；这里不保留仓库名、产品名、接口地址、环境值或用户数据。没有安装依赖、运行构建、启动小程序开发工具或调用线上 API。下文区分源码可直接确认的行为与需要在目标终端复现的风险。

先把会话拆成三种状态

客户端把用户资料和登录/访客标记序列化到 Taro Storage，同时把令牌放在另一个键。这样做能避免把令牌直接塞进渲染状态对象，却引入了两个数据源：UI 读取持久化的 isAuthenticated，请求层读取令牌。源码中请求收到 HTTP 401 时会删除令牌，但没有同步清除 Zustand 中的用户资料、持久化登录标记和相关查询缓存。页面可能继续显示已登录态，直到重新启动或另一个流程修改 store；后续请求也可能在“界面仍是登录、请求却没有令牌”的矛盾状态中继续发出。

建议把会话生命周期明确建模为 unknown、guest、authenticated 三态。启动时先读令牌，再通过受保护的当前用户接口校验；校验完成前不渲染依赖角色的操作。令牌失效、用户主动退出和账号被服务端撤销都调用同一个清理动作：移除令牌、清空用户与私有缓存、重置请求状态，然后导航到安全的访客界面。不要仅凭本地布尔值授予功能，也不要让 API 依赖前端隐藏按钮来实施权限控制。

还有游客状态的命名陷阱：源码的 loginAsGuest() 同时写入 isAuthenticated: true、isGuest: true 和 role: 'guest'。这表示该布尔值在当前实现中更接近“客户端存在一个会话”，并不能单独证明用户完成了账号认证；只检查 isAuthenticated 的页面门禁可能把游客显示成已登录用户。应让 UI 明确区分游客与账号会话；书籍、收藏、个人资料等私有数据仍必须由服务端基于有效令牌和对象权限判定。这里确认的是状态字段语义，不代表游客已能读取服务端私有数据或发生了越权。

type Session =
  | { status: 'unknown' }
  | { status: 'guest' }
  | { status: 'authenticated'; userId: string; token: string };

function clearSession() {
  storage.remove('access-token');
  storage.remove('session-user');
  queryCache.clear();
  sessionStore.setState({ status: 'guest' });
}

示例是设计草图，不是可直接粘贴到所有 Taro 平台的完整适配器；实际实现要用项目统一的 Storage 和导航封装，并确保并发的多个 401 只触发一次清理/跳转。

用户私有数据必须按身份分区

源码把收藏数组放在一个全局本地存储键中，访客、账号 A 和账号 B 共用同一份本地列表。登录后会从服务端同步，但实现只有在服务端返回非空数组时才覆盖本地状态。因此，账号 A 退出后，旧列表可能在账号 B 登录前继续显示；如果账号 B 的真实收藏为空，空响应也不会清除旧数据。该结论来自键名作用域与同步条件的静态读取，不代表我已经在真实设备上复现。

对私有数据，优先使用身份分区键，例如 favorites:<stable-user-id>；访客数据单独保存，且不得自动合并到已登录账号。登录后服务端是权威来源，空数组也是有效结果，必须照常写回。切换账号时先卸载上一个用户的私有缓存，再加载当前用户的数据。若产品确实支持本地离线收藏，应设计明确的合并协议：每一条有稳定 ID、更新时间和来源，冲突策略可预测，注销时不会把未确认的本地变更展示给下一个账号。

本地收藏切换是乐观更新，但网络失败被静默吞掉；界面可能显示“已收藏”，服务端实际却没有保存。应选择一种清晰语义：要么等待服务端成功后再确认，要么保留 pending 状态并失败回滚/提供重试；对于重复点击和断网重放，还要由服务端定义幂等键或最终状态接口，不能假设重复的 toggle 请求等价于重复的“设为收藏”。

async function refreshFavorites(userId: string) {
  const serverItems = await api.getFavorites();
  // 空列表同样是权威结果，不能跳过覆盖。
  localStorage.setItem('favorites:' + userId, JSON.stringify(serverItems));
  favoriteStore.setState({ items: serverItems, status: 'ready' });
}

这里用 Web Storage 仅演示“按用户命名”和“空结果覆盖”的原则。小程序与 H5 应通过平台适配层访问存储；服务端仍须按令牌中的身份过滤收藏，客户端分区只是隐私与体验措施，不是授权边界。

Taro 多端存储的工程边界

Taro 的同步存储 API 适合读取少量启动状态，但同步序列化、异常吞掉和多端持久化差异都要有明确策略。不要在每个 store 中各自实现一套“读失败就当空值”的逻辑，否则磁盘损坏、容量超限和格式升级会伪装成用户主动清空。至少应对 JSON 解析、字段版本、写入失败和迁移失败分别记录不含个人信息的诊断状态；认证失败时则必须按失效处理，而不是继续信任旧的 isAuthenticated。

将令牌与资料分别存储时，写入也要考虑部分成功：令牌写入成功而资料写入失败，或反过来，都不能把状态发布成完整登录。可以用带版本的单一 session envelope 并以临时键加原子替换实现，也可以先写令牌、重新验证后再提交 authenticated 状态。具体选择要考虑 Taro 各目标平台的存储原子性，不能把浏览器 LocalStorage 的行为直接当作所有小程序一致。

主题选择需要跨启动持久化

主题 store 当前有五种静态主题，初始化默认使用橙色主题；切换时更新 Zustand 内存，并同步设置小程序 tabBar 和 H5 CSS，但没有把所选主题写入 Taro Storage。个人页确实调用了主题切换，因此从源码可推断：进程重启后 store 会回到默认主题。这里是静态代码审查结论，尚未通过真实小程序冷启动复现。

建议将用户选择持久化为带版本的轻量偏好，例如 reader-preferences:v1，启动时校验值是否属于已知主题，再应用到页面和 tabBar。读取失败或遇到未来版本值时安全回退默认主题；更新偏好和应用主题应走同一个 action，避免内存、持久化值与原生导航栏三者短暂分叉。测试要覆盖首次启动、切换后杀进程重开、存储损坏、未知主题和 H5/小程序两端的同步。

评论区的请求时序与重复操作

评论组件的加载 effect 使用 targetId 作为依赖，但请求同时使用 targetType。如果组件实例复用时 ID 不变而类型变化，effect 不会因类型更新重新加载。加载请求没有请求代次或取消保护，慢响应可能在用户已切换目标后覆盖当前列表；加载错误被静默捕获，用户难以区分空评论与请求失败。加载更多按钮也没有在请求中禁用。

提交评论没有用进行中状态阻止快速重复提交；点赞则在请求成功后才更新本地已点赞状态，因此短时间连续点击可能发出多个请求。是否造成重复数据还取决于服务端幂等与并发约束，当前结论只是客户端源码暴露出的重复请求风险，不代表已在服务端复现。建议使用 targetId + targetType 作为完整请求身份，为每次加载分配递增 requestId 或 AbortController，并在提交/点赞期间按操作对象禁用按钮；失败要展示可恢复的错误状态，服务端再用幂等键或“设置为已点赞”的幂等接口兜底。

验证时用可控延迟让旧目标请求晚于新目标返回，并快速切换目标、连续提交和连续点赞；断言旧响应不会污染当前列表、重复点击受控、失败可以重试，卸载后不会再更新组件状态。React 官方也要求 effect 声明所读取的响应式依赖，并在清理阶段阻止过期请求结果影响新状态。

登录调试补丁不应全局接管 Toast

登录页模块加载时会包装全局 Taro.showToast；遇到缺失标题的调用，会通过 console.error 输出调用栈与参数对象。它不仅改变全局 API 行为，还可能把调用参数带入控制台日志。应删除页面级 monkeypatch，将参数校验放进项目自有的 toast helper，并只记录经过筛选的错误码或调用位置；不要输出令牌、邮箱、用户输入或完整请求对象。此处只确认源码中存在该调试包装，未声称生产日志已泄露实际个人信息。

需要自动化覆盖的切换矩阵

1. 干净安装启动、损坏 JSON、旧 schema 升级和存储写满：界面进入明确的访客/错误状态，不残留半套会话。
2. 有效令牌、过期令牌、服务端封禁和多个并发 401：用户资料、私有缓存、路由状态一致清理，且只出现一次会话失效提示。
3. 账号 A 有收藏、退出后账号 B 收藏为空：B 只看到服务端空列表；访客列表不会自动并入 A 或 B。
4. 收藏请求成功、超时、断网、重复点击和乱序返回：UI 的 pending/成功/失败状态与服务端最终状态一致，失败可重试且不会静默假成功。
5. 主题选择后杀进程重开、损坏偏好和未知主题值：页面主题与原生 tabBar 一致恢复。
6. 评论目标切换时让旧请求延迟返回，并测试快速提交/点赞、失败重试和组件卸载，确认没有过期覆盖或无提示失败。
7. 在 H5、微信小程序及实际支持的平台分别测冷启动、前后台切换、清缓存和重新登录，不能以单一 H5 页面通过代替跨端验收。

本文是源码级工程复盘，不是构建结果、运行时复现、平台兼容认证或线上故障报告。建议先为会话清理、账号分区、主题恢复与评论时序补单测，再按目标平台做隔离测试；任何显示权限最终仍由服务端校验。

参考：Taro Storage API、Taro 网络请求、React Effect 与依赖、Zustand、OWASP Session Management Cheat Sheet。