Web 端可以用 HttpOnly Cookie但 App 端不能用。所以多端统一登录时不能只依赖 HttpOnly Cookie需要 Token 方案兼容两端。为什么 Web 可以用 HttpOnly Cookie因为浏览器天然支持 Cookie浏览器会自动携带 CookieHttpOnly 能防止 XSS 读取 TokenSameSite 能防 CSRF所以 Web 端用 HttpOnly Cookie 是最安全、最推荐的方式。为什么 App 不能用 HttpOnly Cookie因为App 没有浏览器 Cookie 机制App 无法自动携带 CookieApp 无法读取 HttpOnly Cookie因为 JS 也读不到App 需要自己存储 Token通常是安全存储如 Keychain / Keystore所以 App 端必须使用Authorization: Bearer token或者本地安全存储 手动附带 Token那多端统一登录怎么设计你可以这样回答非常专业多端统一登录时我们通常采用JWT 双 TokenAccess Refresh的方案。 Web 端把 Token 放在 HttpOnly Cookie 中App 端把 Token 放在安全存储中两端都使用同一套 Token 体系但存储方式不同。架构如下端Token 存储方式请求携带方式WebHttpOnly Cookie浏览器自动携带App安全存储Keychain/KeystoreAuthorization Header统一登录的关键点面试官会继续问你可以这样讲1. Token 体系统一Access Token短期有效15min2hRefresh Token长期有效730 天两端都用同一套 Token2. Web 和 App 的存储方式不同WebHttpOnly Cookie防 XSSApp安全存储防逆向、Hook3. 后端统一验证 Token不关心 Token 来自 Cookie 还是 Header只验证签名、过期时间、黑名单等4. 退出登录 / 强制下线使用 Redis 黑名单两端都能立即失效面试官可能追问“那 Web 和 App 怎么同时支持”你可以这样回答后端提供两种 Token 读取方式Web从 Cookie 中读取App从 Authorization Header 中读取认证逻辑统一读取方式不同。这句话非常加分。最终总结你可以直接背多端统一登录时Web 可以用 HttpOnly Cookie但 App 不能使用 Cookie 机制因此不能只依赖 HttpOnly Cookie。我们通常采用 JWT Access/Refresh Token 的统一认证体系Web 把 Token 放在 HttpOnly Cookie 中App 把 Token 放在安全存储中后端统一验证 Token不关心 Token 来自 Cookie 还是 Header从而实现多端统一登录。