Cookie需手动操作document.cookie字符串，易出错；localStorage永久同源存储，sessionStorage仅限单标签页；三者均不安全，敏感信息须后端校验。
Cookie 必须手动操作，没有现成 API
JavaScript 没有内置的 setCookie 或 getCookie 函数，所有 Cookie 操作都靠读写 document.cookie 字符串完成。它本质是拼接键值对的字符串，带分隔符和可选属性（expires、path、domain、Secure、HttpOnly 等），格式脆弱，容易出错。
常见错误包括：
- 忘记设置
expires或max-age，导致变成会话级 Cookie（关闭浏览器即失效） - 路径写错（比如写成
/admin却在/user下读不到） - 没加
SameSite=Strict或Lax，被现代浏览器拦截跨站请求 - 误以为
document.cookie = "a=1"是“设置”，其实只是追加；同名 key 不会覆盖，需手动清除旧值
建议：除非必须服务端参与（如身份认证票据），否则尽量避免直接操作 Cookie；若需前端管理，用封装好的工具函数或库（如 js-cookie）。
localStorage 和 sessionStorage 的 API 完全一致但生命周期不同
两者都提供 setItem()、getItem()、removeItem()、clear() 四个方法，且只支持字符串值。存对象必须先 JSON.stringify()，取出来要 JSON.parse()。
立即学习“Java免费学习笔记（深入）”；
关键区别在作用域和持久性：
-
localStorage：同源下永久保存，除非手动调用clear()或用户清空浏览器数据 -
sessionStorage：仅限当前标签页（tab）生命周期，关闭该 tab 即销毁；新开 tab 或同一页面刷新都保留 - 两者都不随 HTTP 请求自动发送，不占用带宽，也不受
SameSite限制
典型使用场景：
-
localStorage：用户主题偏好、长期登录态标记（配合服务端 token 验证）、离线缓存配置 -
sessionStorage：表单草稿临时暂存、支付流程中的中间状态、防止重复提交的 nonce
别往 localStorage/sessionStorage 存敏感信息
它们完全暴露在前端，任何脚本（包括第三方库、XSS 注入代码）都能读取。即使加密，密钥也得存在 JS 里，等于没锁。
真实风险示例：
- 存了 JWT token？攻击者 XSS 后一行
localStorage.getItem('token')就拿到 - 存了用户手机号或邮箱？爬虫类脚本可批量提取
- 存了加密后的密码？只要解密逻辑在前端，就可逆向还原
正确做法：
- 敏感操作（如支付、修改密码）始终由后端校验权限，前端只做体验优化
- 需要本地缓存用户标识时，用短期有效的随机 session id，而非原始凭证
- 若必须加密，密钥应由服务端动态下发，且有效期极短
注意存储容量和异常处理
虽然规范说至少 5MB，但实际中：
- Chrome / Edge 对
localStorage单域名限制约 10MB，sessionStorage类似 - Safari 在无痕模式下可能直接禁用
localStorage，调用setItem()会抛QuotaExceededError - iOS WebView 中某些版本对
localStorage写入有延迟或丢失问题
务必加 try-catch：
try {
localStorage.setItem('config', JSON.stringify(data));
} catch (e) {
if (e.name === 'QuotaExceededError') {
console.warn('Local storage full, fallback to memory cache');
}
}
另外，localStorage 的写入是同步阻塞的，大量数据（如日志堆积）可能卡 UI；高频写入建议节流或改用 IndexedDB。
