怎么使用javascript的本地存储_cookie、localStorage和sessionStorage有何区别？

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。

真正麻烦的不是记不住三者区别，而是默认认为“能存进去就安全可用”。Cookie 的路径/域陷阱、localStorage 的 XSS 泄露、sessionStorage 的标签页隔离边界——这些细节一旦漏掉，上线后就是线上事故。