不推荐用 Cookie 存储敏感身份信息，应优先使用 HttpOnly+Secure Cookie 配合后端鉴权，前端临时用内存变量存 token，禁用明文存储与 localStorage；现代方案首选 OAuth 2.1 或 Web Crypto 加密存储。

JavaScript 操作 Cookie 本身简单，但不推荐用 Cookie 存储敏感身份信息（如 token、用户ID、密码），尤其不能明文存、不设安全属性。真正安全的身份信息存储，应结合后端配合、前端规范使用与现代替代方案。

Cookie 基础操作（仅限必要场景）

浏览器原生提供 document.cookie 接口，但它是字符串读写接口，需手动解析和拼接：

• 设置（带安全限制）：
  document.cookie = "auth_token=abc123; path=/; secure; HttpOnly=false; SameSite=Lax; max-age=3600";
• 读取（需自行解析）：
  const cookies = document.cookie.split('; ').reduce((acc, pair) => { const [k, v] = pair.split('='); acc[k] = decodeURIComponent(v); return acc; }, {});
• 删除：设过期时间为过去时间，例如 document.cookie = "auth_token=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/;"

⚠️ 注意：HttpOnly Cookie 无法被 JS 读取（防 XSS），所以若需前端访问 token，HttpOnly=false，但必须搭配其他防护手段。

为什么不能直接用 Cookie 存敏感身份信息？

• XSS 攻击可窃取非 HttpOnly Cookie 中的 token
• 明文传输（未启用 HTTPS）时，Cookie 内容可被中间人截获
• 跨站请求（CSRF）可能被滥用，除非严格配置 SameSite 和验证 CSRF Token
• Cookie 自动随请求发送，增大攻击面；而前端可控的存储方式（如内存变量）更精准

更安全的身份信息管理实践

• 优先使用 HttpOnly + Secure Cookie 存 token：由后端颁发、签名、设 Secure（仅 HTTPS）、SameSite=Strict/Lax，前端无需读取，仅用于自动鉴权
• 前端如需临时使用 token（如调用 API）：从内存（如闭包变量、模块级常量）中获取，不用 localStorage/sessionStorage —— 它们易受 XSS 读取
• 登录态校验双保险：后端每次敏感请求验证 token 有效性 + 签名 + 可选设备指纹或短期刷新机制
• 敏感操作二次确认：如修改密码、支付前，要求重新输入密码或短信验证，不依赖长期 token

现代替代方案：推荐优先考虑

• OAuth 2.1 / OpenID Connect：由授权服务器统一管理令牌生命周期，前端只持短期 access_token（建议存在内存，不用持久化）
• Web Crypto API + 加密存储：极少数需本地缓存加密凭证的场景，可用 SubtleCrypto 加密后存入 IndexedDB（仍不如服务端托管安全）
• Session Storage（仅会话级）：比 localStorage 稍安全（关闭标签即销毁），但仍不防 XSS，仅适合非敏感临时数据