Cookie、localStorage、sessionStorage 怎么选
先理解原理和示例，再练习完整口述与追问。
回答要点
Cookie 可按规则随请求发送，HttpOnly Cookie 不能由 JS 读取；localStorage 按源持久化，sessionStorage 按源及页面会话隔离。结合容量、生命周期、SSR、XSS 和 CSRF 风险回答，不要说“token 放哪里绝对安全”。
原理拆解
Cookie 由浏览器依据域、路径、安全属性等规则随请求携带，适合服务端会话；HttpOnly 限制脚本读取，但不会阻止同源恶意脚本发起用户操作。localStorage 按 origin 持久保存字符串，sessionStorage 主要与当前顶层浏览上下文会话关联；两者不会自动作为认证头发给后端，且同步访问可能阻塞。
示例与推演
会话 Cookie 可由服务端设置 HttpOnly、Secure 与适当 SameSite，并配合服务端会话校验和 CSRF 防护。主题选择、非敏感筛选项可使用 localStorage；临时编辑进度可根据恢复要求选择 sessionStorage 或服务端草稿。SSR 无法读取浏览器 localStorage，若首屏依赖认证或主题，应从请求 Cookie 等服务器可见信息决定。
易错点
不要把“localStorage 不自动携带”当成免疫 XSS，也不要把 HttpOnly 当成免疫所有攻击。Cookie 的 Domain 和 Path 不是完整权限隔离工具，退出还需服务端使会话失效。
参考回答可直接练习口述
Cookie 按域、路径、SameSite 等规则随请求发送，HttpOnly 可阻止 JS 直接读取，Secure 限制安全传输。localStorage 按源持久保存，sessionStorage 还按页面会话隔离，它们都能被同源脚本读取，因此有 XSS 风险。认证存储要结合服务端方案：HttpOnly Cookie 可降低凭证被脚本直接窃取的风险，但仍需防 CSRF；把 token 放 storage 则不能忽略 XSS。SSR 只能从请求等服务端可用上下文取凭证。