共用用户资料，分别建立会话
官网通过 /api/v1/me 读取当前用户，没有新增 Web 专用用户表。一个账户可以拥有多个会话，撤销操作针对会话标识执行。手机和浏览器能显示一致资料，同时保留各自的登录生命周期。
第一次打开网站仍需登录。若项目要求跨站单点登录，需要另外设计授权跳转和回调校验；不能把手机 Token 放进 URL 交给网页。查询参数容易进入浏览记录、访问日志和第三方跳转链，不能承载这类凭据。
语言与时区作为用户资料保存。网站切换界面语言后，还要区分匿名本地偏好和登录用户的服务端偏好；后者应检查保存结果，失败时提示用户。
浏览器会话由 Web 服务端处理
官网使用同源 BFF：页面调用网站的会话接口，Next.js 再调用配置好的 App API。Access Token、Refresh Token 和设备标识存入 HttpOnly Cookie，路径限定在 /api/session，生产环境设置 Secure。客户端 JSON 和 localStorage 不返回或保存这些令牌。
写请求检查 Origin 与站点来源，业务接口采用显式允许列表。部署时应使用 HTTPS 并配置准确的站点地址。HttpOnly 限制脚本读取 Cookie，但不会替代来源校验、接口授权和页面脚本安全。
App 的 Access Token 保存在内存，Refresh Token 经安全存储封装保存。语言等非敏感设置可以进入普通本地存储；密码、验证码和会话凭据需要与这些设置分开。
图示用于解释存储与认证边界，未表示跨站单点登录或生产部署状态。
重载页面时先恢复身份
浏览器重载会清空页面内存，Cookie 仍可能有效。账户组件应先进入加载状态，调用会话接口读取资料，再决定显示账户页或登录入口。仅检查初始内存值会把尚未恢复的用户当作匿名访客。
当前官网在短期凭据缺失或过期时尝试轮换 Refresh Token，并重新读取 /me。会话确实无效时清除 Cookie；后端超时、限流或暂时不可用时保留可恢复错误。否则一次网络抖动就会迫使用户重新输入密码。
并发刷新有部署上限
多个标签页可能同时读取资料与收藏，若它们各自消费同一枚 Refresh Token，后来的请求可能遇到旧令牌已使用。官网在支持 Web Locks 的浏览器中串行协调会话请求，服务端也在一个 Web 进程内共享同次轮换结果。
进程内协调不覆盖多个 Web 实例。横向扩容前需要共享的会话协调方案，并重新验证多标签页、Cookie 更新和并发轮换。不能把单实例检查当作分布式环境的验收。
业务写入先完成身份检查，再发送一次。请求已发出而响应丢失时，客户端无法凭错误状态知道数据库是否已保存；没有幂等保证的操作不能直接自动重试。
账户接入验收清单
用两个独立客户端登录同一测试账户，确认用户资料相同、会话标识不同。修改语言后读取后端值，撤销其中一个会话后尝试恢复，再按接口规则检查另一会话是否仍有效。
继续测试仅保留刷新凭据的真实重载、API 暂时不可用、退出后访问受保护接口，以及携带不同 App 上下文的请求。收藏再增加重复保存测试。截图能说明页面状态，Cookie 轮换和权限结果还需查看实际请求。
注册页面要求已发布用户协议和隐私政策。注册验证与真实邮件找回需要可用的邮件渠道，这几项应分别验收。实现约定参见App API及Next.js 认证文档。