不推荐用 Cookie 存储敏感身份信息，应优先使用 HttpOnly+Secure Cookie 配合后端鉴权，前端临时用内存变量存 token，禁用明文存储与 localStorage；现代方案首选 OAuth 2.1 或 Web Crypto 加密存储。
JavaScript 操作 Cookie 本身简单，但不推荐用 Cookie 存储敏感身份信息（如 token、用户ID、密码），尤其不能明文存、不设安全属性。真正安全的身份信息存储，应结合后端配合、前端规范使用与现代替代方案。
Cookie 基础操作（仅限必要场景）
浏览器原生提供 document.cookie 接口，但它是字符串读写接口，需手动解析和拼接：
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 设置（带安全限制）：
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 攻击可窃取非
HttpOnlyCookie 中的 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，仅适合非敏感临时数据
