一、登录成功之后真正困难的是“不串数据”球友甲登录后创建了一场周末对局退出账号再让球友乙登录同一台设备。如果页面仍然显示甲的对局、邀请码或个人胜率认证虽然成功数据边界却已经失效。账号系统不能只回答“当前有没有 token”还要回答“当前所有持久化数据属于谁”。羽球搭子的处理方式是把认证会话和业务数据分开保存。认证存储负责 token、过期时间和用户资料对局存储、云端会话状态再读取稳定的用户 ID生成各自的持久化键。昵称不会参与新的作用域计算因为昵称允许修改也可能重名。这样登录、退出和切换账号时应用可以清空内存镜像再从新作用域恢复数据。这套边界解决的是本机多账号隔离不等同于服务端权限。服务端仍然必须根据令牌校验资源归属客户端作用域负责避免旧账号数据在界面上短暂泄漏并保证离线缓存不会互相覆盖。二、认证会话只保存身份不直接承载业务对象认证存储中只需要三类值访问令牌、绝对过期时间和用户资料。登录接口通常返回相对秒数保存时立即换算成绝对时间后续每次取 token 都做过期判断。令牌为空或已经过期时业务层统一得到空字符串不需要每个页面重复比较时间。export class AuthSessionStore { static readonly TOKEN cloud_auth_token static readonly EXPIRES_AT cloud_auth_expires_at static readonly USER cloud_auth_user static save(session: AuthSession): void { const expiresAt Date.now() session.expiresIn * 1000 AppStorage.setOrCreatestring(this.TOKEN, session.token) AppStorage.setOrCreatenumber(this.EXPIRES_AT, expiresAt) AppStorage.setOrCreateUserProfile(this.USER, session.user) this.persist(session.token, expiresAt, session.user) } static getToken(): string { const token AppStorage.getstring(this.TOKEN) ?? const expiresAt AppStorage.getnumber(this.EXPIRES_AT) ?? 0 return token.length 0 expiresAt Date.now() ? token : } }这里有一个刻意的取舍运行期 AppStorage 更新成功后即使 Preferences 刷盘失败当前页面仍可继续使用但下次冷启动可能需要重新登录。认证存储不应该在持久化异常时伪装成完整成功因此界面可以在关键操作前再次检查getToken()服务端请求也必须允许返回未授权错误。数据适合的存储位置原因失效动作token认证存储请求鉴权需要生命周期独立过期或退出时删除expiresAt认证存储避免使用过期 token每次读取时比较userId、昵称、头像认证存储页面展示及作用域选择用户资料更新时覆盖对局摘要与详情对局存储需要离线使用和重启恢复按 userId 分区云端版本、邀请码、别名云会话存储用于同步和冲突判断按 userId 分区三、稳定 userId 进入键空间业务存储不把所有账号的数据写入同一个sessions键而是先计算作用域。已登录用户使用服务端返回的稳定 ID未登录状态保留默认键继续支持本地离线使用。这样两个账号的同名对局也不会相互覆盖。function currentScope(): string { const user AuthSessionStore.getUser() if (user ! undefined user.id.length 0) { return u_${user.id}_ } return } function scopedKey(baseKey: string): string { const scope currentScope() return scope.length 0 ? baseKey : ${scope}${baseKey} } function detailKey(sessionId: string): string { return scopedKey(session_${sessionId}) }作用域前缀不是加密也不是权限控制。它只是明确“哪一份本地缓存属于哪位用户”。如果攻击者能够直接读取应用沙箱仍需要系统沙箱、设备锁和敏感数据保护提供安全边界。服务端接口更不能信任客户端拼出的 userId而应从令牌解析身份。四、从旧键迁移到新作用域要可重复应用早期可能只有一个无作用域键或者曾经用昵称哈希区分用户。升级后直接只读新键会让用户误以为历史对局丢失。恢复逻辑因此按“新作用域 → 无作用域旧键 → 昵称旧键”的顺序查找找到旧数据后写入新键但不在读到第一份数据前删除旧值。function readSessions(prefs: Preferences): string { const primary prefs.getSync(scopedKey(g_sessions), ) as string if (primary.length 0) { return primary } const unscoped currentScope().length 0 ? prefs.getSync(g_sessions, ) as string : if (unscoped.length 0) { prefs.putSync(scopedKey(g_sessions), unscoped) return unscoped } const legacy prefs.getSync(legacyScopedKey(g_sessions), ) as string if (legacy.length 0) { prefs.putSync(scopedKey(g_sessions), legacy) } return legacy }迁移必须具备幂等性第一次启动完成复制第二次启动首先命中新键不再产生不同结果。旧数据是否删除应由独立的版本迁移策略决定不能夹在页面加载中立即清理否则一次解析异常就可能同时破坏新旧两份数据。五、切换账号时先清镜像再恢复目标作用域退出账号的关键动作不是把按钮文字改成“未登录”而是让依赖账号的内存状态立即失效。对局摘要、当前场次、云端会话版本和统计结果都可能仍在 AppStorage 中。正确顺序是清除认证会话重置账号模式重新恢复账号作用域存储最后刷新页面派生状态。function switchAccount(next: AuthSession | undefined): void { if (next undefined) { AuthSessionStore.clear() } else { AuthSessionStore.save(next) } SessionStore.clearRuntimeMirror() CloudSessionStateStore.clearRuntimeMirror() CloudSessionStateStore.hydrateFromPrefs() SessionStore.hydrateFromPrefs() StatsViewModel.reload() }这里“先清再读”非常重要。如果直接覆盖少数字段目标账号没有某项数据时上一账号的旧值可能继续留在页面。清理动作只针对运行期镜像不应粗暴清空整个 Preferences 文件否则退出账号会连带删除其他账号的离线数据。六、页面只消费可观察结果页面不需要知道作用域键的具体格式。它只订阅登录态、当前用户名、对局列表和统计模型并通过统一方法触发重新装载。认证成功、退出和用户资料更新都走同一条刷新路径避免“首页已经切换统计页还是旧账号”的局部更新。class AccountViewModel { Trace signedIn: boolean false Trace userName: string Trace sessions: SessionSummary[] [] reload(): void { const user AuthSessionStore.getUser() this.signedIn AuthSessionStore.getToken().length 0 this.userName this.signedIn ? user?.nickname ?? : this.sessions SessionStore.list() } signOut(): void { AuthRepository.signOut() AccountScopedStores.reload() this.reload() } }页面层保留加载态和错误态但不自行拼接持久化键。只要作用域逻辑集中在 Store 内部将来调整键格式或增加迁移版本时就不需要逐页修改。七、五条失败路径决定隔离是否可靠场景容易出现的错误防护策略可见结果token 已过期页面仍显示已连接读取 token 时统一校验绝对时间回到未登录态账号 A 退出、B 登录A 的 AppStorage 残留先清运行期镜像再恢复 BB 只看到自己的数据用户修改昵称本地作用域变化新作用域只使用稳定 userId数据保持不变旧版本无作用域数据升级后历史为空按顺序读取并迁移旧键首次启动完成兼容Preferences 数据损坏JSON 解析中断捕获异常并使用空模型页面可继续进入还要警惕“退出即删除全部本地数据”的过度清理。多数情况下退出只是断开云端身份用户再次登录仍希望恢复自己的离线对局。真正的本地清除应该是独立、明确、带确认的设置操作。八、怎样验证没有串号验收至少准备两个测试账号和一份未登录数据。账号 A 创建对局并设为当前场次退出后确认页面先变为空账号 B 登录创建不同名称的对局再次切回 AA 的列表和当前场次应恢复。随后修改 A 的昵称确认数据仍归属于同一 userId。冷启动验证同样必要分别在 A、B 登录状态下结束进程并重启确认认证过期判断、作用域恢复和页面刷新顺序一致。再构造一个已经过期的绝对时间应用应拒绝返回 token而不是等服务端第一次报错才改变界面。Preferences 的具体能力和约束应以 HarmonyOS ArkData Preferences 官方指南 为准。账号隔离设计还应结合目标 SDK 的数据保护要求和服务端鉴权策略复核。九、总结账号认证后的数据作用域是一条完整链路认证会话提供稳定 userId业务 Store 用它生成键空间账号切换先清运行期镜像再从目标作用域恢复页面只消费恢复后的可观察状态。昵称、头像和页面文案都不能代替稳定身份。这套实现让本地离线与云端账号可以共存未登录用户继续使用默认分区登录用户拥有独立缓存旧版本数据通过幂等迁移进入新键。它不能替代服务端权限控制却能把同机多账号最常见的串数据问题挡在 UI 出现之前。
一、登录成功之后真正困难的是“不串数据”球友甲登录后创建了一场周末对局退出账号再让球友乙登录同一台设备。如果页面仍然显示甲的对局、邀请码或个人胜率认证虽然成功数据边界却已经失效。账号系统不能只回答“当前有没有 token”还要回答“当前所有持久化数据属于谁”。羽球搭子的处理方式是把认证会话和业务数据分开保存。认证存储负责 token、过期时间和用户资料对局存储、云端会话状态再读取稳定的用户 ID生成各自的持久化键。昵称不会参与新的作用域计算因为昵称允许修改也可能重名。这样登录、退出和切换账号时应用可以清空内存镜像再从新作用域恢复数据。这套边界解决的是本机多账号隔离不等同于服务端权限。服务端仍然必须根据令牌校验资源归属客户端作用域负责避免旧账号数据在界面上短暂泄漏并保证离线缓存不会互相覆盖。二、认证会话只保存身份不直接承载业务对象认证存储中只需要三类值访问令牌、绝对过期时间和用户资料。登录接口通常返回相对秒数保存时立即换算成绝对时间后续每次取 token 都做过期判断。令牌为空或已经过期时业务层统一得到空字符串不需要每个页面重复比较时间。export class AuthSessionStore { static readonly TOKEN cloud_auth_token static readonly EXPIRES_AT cloud_auth_expires_at static readonly USER cloud_auth_user static save(session: AuthSession): void { const expiresAt Date.now() session.expiresIn * 1000 AppStorage.setOrCreatestring(this.TOKEN, session.token) AppStorage.setOrCreatenumber(this.EXPIRES_AT, expiresAt) AppStorage.setOrCreateUserProfile(this.USER, session.user) this.persist(session.token, expiresAt, session.user) } static getToken(): string { const token AppStorage.getstring(this.TOKEN) ?? const expiresAt AppStorage.getnumber(this.EXPIRES_AT) ?? 0 return token.length 0 expiresAt Date.now() ? token : } }这里有一个刻意的取舍运行期 AppStorage 更新成功后即使 Preferences 刷盘失败当前页面仍可继续使用但下次冷启动可能需要重新登录。认证存储不应该在持久化异常时伪装成完整成功因此界面可以在关键操作前再次检查getToken()服务端请求也必须允许返回未授权错误。数据适合的存储位置原因失效动作token认证存储请求鉴权需要生命周期独立过期或退出时删除expiresAt认证存储避免使用过期 token每次读取时比较userId、昵称、头像认证存储页面展示及作用域选择用户资料更新时覆盖对局摘要与详情对局存储需要离线使用和重启恢复按 userId 分区云端版本、邀请码、别名云会话存储用于同步和冲突判断按 userId 分区三、稳定 userId 进入键空间业务存储不把所有账号的数据写入同一个sessions键而是先计算作用域。已登录用户使用服务端返回的稳定 ID未登录状态保留默认键继续支持本地离线使用。这样两个账号的同名对局也不会相互覆盖。function currentScope(): string { const user AuthSessionStore.getUser() if (user ! undefined user.id.length 0) { return u_${user.id}_ } return } function scopedKey(baseKey: string): string { const scope currentScope() return scope.length 0 ? baseKey : ${scope}${baseKey} } function detailKey(sessionId: string): string { return scopedKey(session_${sessionId}) }作用域前缀不是加密也不是权限控制。它只是明确“哪一份本地缓存属于哪位用户”。如果攻击者能够直接读取应用沙箱仍需要系统沙箱、设备锁和敏感数据保护提供安全边界。服务端接口更不能信任客户端拼出的 userId而应从令牌解析身份。四、从旧键迁移到新作用域要可重复应用早期可能只有一个无作用域键或者曾经用昵称哈希区分用户。升级后直接只读新键会让用户误以为历史对局丢失。恢复逻辑因此按“新作用域 → 无作用域旧键 → 昵称旧键”的顺序查找找到旧数据后写入新键但不在读到第一份数据前删除旧值。function readSessions(prefs: Preferences): string { const primary prefs.getSync(scopedKey(g_sessions), ) as string if (primary.length 0) { return primary } const unscoped currentScope().length 0 ? prefs.getSync(g_sessions, ) as string : if (unscoped.length 0) { prefs.putSync(scopedKey(g_sessions), unscoped) return unscoped } const legacy prefs.getSync(legacyScopedKey(g_sessions), ) as string if (legacy.length 0) { prefs.putSync(scopedKey(g_sessions), legacy) } return legacy }迁移必须具备幂等性第一次启动完成复制第二次启动首先命中新键不再产生不同结果。旧数据是否删除应由独立的版本迁移策略决定不能夹在页面加载中立即清理否则一次解析异常就可能同时破坏新旧两份数据。五、切换账号时先清镜像再恢复目标作用域退出账号的关键动作不是把按钮文字改成“未登录”而是让依赖账号的内存状态立即失效。对局摘要、当前场次、云端会话版本和统计结果都可能仍在 AppStorage 中。正确顺序是清除认证会话重置账号模式重新恢复账号作用域存储最后刷新页面派生状态。function switchAccount(next: AuthSession | undefined): void { if (next undefined) { AuthSessionStore.clear() } else { AuthSessionStore.save(next) } SessionStore.clearRuntimeMirror() CloudSessionStateStore.clearRuntimeMirror() CloudSessionStateStore.hydrateFromPrefs() SessionStore.hydrateFromPrefs() StatsViewModel.reload() }这里“先清再读”非常重要。如果直接覆盖少数字段目标账号没有某项数据时上一账号的旧值可能继续留在页面。清理动作只针对运行期镜像不应粗暴清空整个 Preferences 文件否则退出账号会连带删除其他账号的离线数据。六、页面只消费可观察结果页面不需要知道作用域键的具体格式。它只订阅登录态、当前用户名、对局列表和统计模型并通过统一方法触发重新装载。认证成功、退出和用户资料更新都走同一条刷新路径避免“首页已经切换统计页还是旧账号”的局部更新。class AccountViewModel { Trace signedIn: boolean false Trace userName: string Trace sessions: SessionSummary[] [] reload(): void { const user AuthSessionStore.getUser() this.signedIn AuthSessionStore.getToken().length 0 this.userName this.signedIn ? user?.nickname ?? : this.sessions SessionStore.list() } signOut(): void { AuthRepository.signOut() AccountScopedStores.reload() this.reload() } }页面层保留加载态和错误态但不自行拼接持久化键。只要作用域逻辑集中在 Store 内部将来调整键格式或增加迁移版本时就不需要逐页修改。七、五条失败路径决定隔离是否可靠场景容易出现的错误防护策略可见结果token 已过期页面仍显示已连接读取 token 时统一校验绝对时间回到未登录态账号 A 退出、B 登录A 的 AppStorage 残留先清运行期镜像再恢复 BB 只看到自己的数据用户修改昵称本地作用域变化新作用域只使用稳定 userId数据保持不变旧版本无作用域数据升级后历史为空按顺序读取并迁移旧键首次启动完成兼容Preferences 数据损坏JSON 解析中断捕获异常并使用空模型页面可继续进入还要警惕“退出即删除全部本地数据”的过度清理。多数情况下退出只是断开云端身份用户再次登录仍希望恢复自己的离线对局。真正的本地清除应该是独立、明确、带确认的设置操作。八、怎样验证没有串号验收至少准备两个测试账号和一份未登录数据。账号 A 创建对局并设为当前场次退出后确认页面先变为空账号 B 登录创建不同名称的对局再次切回 AA 的列表和当前场次应恢复。随后修改 A 的昵称确认数据仍归属于同一 userId。冷启动验证同样必要分别在 A、B 登录状态下结束进程并重启确认认证过期判断、作用域恢复和页面刷新顺序一致。再构造一个已经过期的绝对时间应用应拒绝返回 token而不是等服务端第一次报错才改变界面。Preferences 的具体能力和约束应以 HarmonyOS ArkData Preferences 官方指南 为准。账号隔离设计还应结合目标 SDK 的数据保护要求和服务端鉴权策略复核。九、总结账号认证后的数据作用域是一条完整链路认证会话提供稳定 userId业务 Store 用它生成键空间账号切换先清运行期镜像再从目标作用域恢复页面只消费恢复后的可观察状态。昵称、头像和页面文案都不能代替稳定身份。这套实现让本地离线与云端账号可以共存未登录用户继续使用默认分区登录用户拥有独立缓存旧版本数据通过幂等迁移进入新键。它不能替代服务端权限控制却能把同机多账号最常见的串数据问题挡在 UI 出现之前。
