Cookie适合存短标识符、有效期明确的认证票据等小体积服务端需用的状态；不适合存JSON、图片、频繁读写的UI状态等大体积或前端专用数据。
cookie 适合存什么，不适合存什么
cookie 主要用于服务端需要参与的状态管理，比如登录凭证 sessionid、CSRF token、用户偏好（需和服务端同步的）等。它会随每个 HTTP 请求自动携带，所以体积必须小——浏览器通常限制单个 cookie 不超过 4KB，且同域名下总 cookie 数量和大小都有硬限制。
常见错误是把大量数据（如用户行为日志、长文本配置）塞进 cookie，结果导致请求头膨胀、首屏变慢，甚至触发 Nginx 的 400 Bad Request（因 header 超限）。
- ✅ 适合：短标识符（
"uid=abc123"）、有效期明确的认证票据（Expires或Max-Age可控） - ❌ 不适合：JSON 对象、base64 图片、频繁读写的 UI 状态（如折叠菜单展开项）
- ⚠️ 注意：
HttpOnlycookie 无法被 JavaScript 读取，仅服务端可用；Secure表示只在 HTTPS 下发送
localStorage 更适合前端独立维护的状态
localStorage 是纯前端存储，容量大（通常 5MB 左右），不随请求发送，读写都通过 JS API，适合存那些只在浏览器内生效、无需服务端感知的数据。
但它没有过期机制，除非手动调用 removeItem() 或 clear()，否则数据永久存在；而且它是同步阻塞 API，在主线程里操作大对象（比如存一个 2MB 的 JSON 字符串）会导致页面卡顿。
立即学习“Java免费学习笔记（深入）”；
- ✅ 适合：用户主题设置（
"theme=dark"）、表单草稿、离线缓存的 API 响应（配合版本 key 控制） - ❌ 不适合：敏感信息（如 token），因为 XSS 攻击可直接读取；也不适合跨域共享（同源策略严格限制）
- ⚠️ 注意：
localStorage.setItem()只接受字符串，存对象必须先JSON.stringify()；取值后需JSON.parse()，否则是字符串类型
遇到“存不下”或“取不到”时先查这三件事
很多问题不是选错方案，而是没处理好边界条件。比如存了但刷新后消失、多标签页不同步、Safari 隐私模式报错等。
- 检查是否在
file://协议下运行——localStorage和cookie在本地文件协议中多数浏览器默认禁用 - 确认当前域名和协议一致：从
http://a.com设置的localStorage，在https://a.com下完全不可见；子域名间也互不可见（a.example.com≠b.example.com） - 捕获异常再操作：
localStorage在 Safari 无痕模式或存储满时会直接抛QuotaExceededError，不加try/catch就中断后续逻辑
try {
localStorage.setItem('userPrefs', JSON.stringify({ theme: 'dark', lang: 'zh' }));
} catch (e) {
if (e.name === 'QuotaExceededError') {
console.warn('localStorage quota exceeded');
}
}
别忽略 sessionStorage 和 IndexedDB 这两个备选
如果需求是“关掉这个 tab 就丢掉数据”，sessionStorage 比 localStorage 更精准，它的生命周期绑定到页面会话（tab），且同样支持字符串存取，API 完全一致。
而当你要存结构化数据、需要索引、查询或大于 5MB 时，localStorage 就力不从心了。IndexedDB 是异步、事务性、支持二进制的客户端数据库，虽然 API 繁琐，但现代封装库（如 idb）已大幅降低使用门槛。
- 临时表单草稿 →
sessionStorage - 用户个性化配置 →
localStorage - 离线邮件列表 + 附件预览 →
IndexedDB - 登录态透传给后端 →
cookie（带HttpOnly和Secure）
真正容易被忽略的是：cookie 的 SameSite 属性。Chrome 80+ 默认为 Lax，跨站 POST 请求不会带上 cookie，导致“明明登录了却提示未授权”。这时候不能靠换 localStorage 解决，得改服务端 Set-Cookie 头或前端跳转逻辑。
