记住账号与自动登录的实现边界

“记住账号”只保存登录页的显示提示；“记住我”或自动登录涉及恢复经过服务端验证的会话。两者不能用同一个本地文件是否存在来判断。

数据	用途	能否证明已登录
用户名、头像、上次使用的账号	展示账号选择列表	不能
服务端认可的 session / refresh 凭据	恢复或续期登录	必须重新验证有效性与账户状态
remember: true	表达持久登录偏好	不能

保存账号提示

登录成功后，可按用户选择保存最少的账号显示信息。打开登录界面时读取并预填，用户仍需认证。浏览器可使用适合该数据的本地存储；桌面端可使用应用数据文件或数据库。

这些数据可能泄露设备上使用过的账号，因此应提供删除入口；本地记录不应包含密码或被当作授权依据。

恢复登录

点击账号卡片只能发起恢复流程，不能直接信任卡片中的 user ID。服务端要验证凭据、过期、撤销及账户状态，成功后才建立当前身份。

• 浏览器：可使用服务端 Session Cookie，或按架构使用短期 Access Token 与长期 Refresh Token。Cookie 凭据需考虑 HttpOnly、Secure、SameSite 与 CSRF，详见 cookie-session-token。
• 桌面客户端：持久凭据应使用平台凭据存储能力，并隔离不同账号；普通 JSON 文件或本地数据库本身不提供安全保护。
• 纯离线应用：本地解锁是另一种威胁模型，不能把“单机”直接等同于可以长期保存密码或无限期 token。

“把密码加密保存后自动提交”不是默认的记住我方案。Token 也不一定需要加密；关键是传输保护、凭据保密、校验与生命周期控制，签名 JWT 本身不隐藏载荷。

具体的刷新、并发、失败重试和撤销流程复用 token-auth-implementation-flow，不在本页复制协议。

退出与删除记录

退出应撤销当前会话或 refresh family，并清除客户端凭据。删除账号卡片只是删除显示记录；它不自动撤销服务器上的登录。已签发 Access Token 的即时失效也取决于验证架构。

检查场景

• 只保留账号提示、删除登录凭据后，应要求重新认证。
• 修改本地卡片的 user ID，不能切换到另一个用户的权限。
• 会话过期或被撤销后，自动登录应收口到重新认证；网络暂时失败与明确撤销要区分。
• 多账号切换不能复用上一账号的凭据和缓存身份。

[!info] related notes

• account-module：账号资料与生命周期。
• authentication-module：认证与会话管理。
• token-auth-implementation-flow：Access / Refresh 的具体流程。