localStorage适合存前端专属数据（如用户偏好、UI状态），cookie适合存需服务端参与的小型关键数据（如HttpOnly登录态）；选型依据是读取主体、时机及是否需发往服务器。
localStorage 适合存什么，cookie 适合存什么
选哪个不看“功能多不多”，而要看“谁需要读、什么时候读、要不要发给服务器”。localStorage 是纯前端的键值对存储，浏览器关了还在，但服务端完全看不见；cookie 会随每次 HTTP 请求自动带上，服务端能读能写，但有大小限制（通常 4KB）、有同源策略和安全标记（HttpOnly、Secure）约束。
常见分工：
- 用户偏好设置、UI 主题、折叠状态 →
localStorage - 登录态 token（尤其是需要服务端校验的）→
cookie（配合HttpOnly防 XSS） - 临时缓存少量接口响应（且无需服务端参与）→
localStorage或sessionStorage - 跨子域共享小数据（如统一登录标识）→
cookie（设Domain=.example.com）
用 JavaScript 操作 cookie 很麻烦，别手写
原生 document.cookie 是个怪异的字符串接口：读是拼接的键值对（a=1; b=2; c=3），写要手动拼 key=value; expires=...; path=/; secure，还容易漏分号或编码错误。直接手写极易出错，比如中文没 encodeURIComponent、过期时间格式错、路径没设导致读不到。
建议用轻量库或封装函数：
立即学习“Java免费学习笔记（深入）”；
- 简单项目：用
js-cookie（npm install js-cookie），一行读写：Cookie.set('token', 'abc123', { expires: 7, secure: true, sameSite: 'Strict' }) - 不想引入依赖：封装一个
setCookie函数，必须处理encodeURIComponent、默认path=/、支持maxAge（比expires更可靠） - 绝对不要在
cookie里存敏感信息（如密码、完整 token）——除非加了HttpOnly且前端只负责触发登录，不读 token 内容
localStorage 的坑比想象中多
它看起来简单，但实际用起来有几个硬伤：
- 只能存字符串：存对象必须
JSON.stringify()，取出来得JSON.parse()，否则是[object Object] - 没有过期机制：不能像 cookie 那样自动失效，得自己记时间戳+手动清理
- 同步阻塞：大体积数据（>5MB）读写可能卡主线程，尤其低端设备
- 同源限制严格：子域名之间（
a.example.com和b.example.com）完全隔离，无法共享 - 隐私模式下部分浏览器会拒绝写入（Safari 尤其激进），应加 try/catch 并降级到内存存储
示例安全写法：
try {
localStorage.setItem('userPrefs', JSON.stringify({ theme: 'dark', lang: 'zh' }))
} catch (e) {
// 可能是隐私模式或超出配额，fallback 到内存对象
window._fallbackStorage = { theme: 'dark', lang: 'zh' }
}
别让 cookie 和 localStorage 做对方的工作
常见反模式：
- 把大段 HTML 片段存在
cookie里 → 超出 4KB，请求头膨胀，拖慢所有请求 - 把 JWT 存
localStorage后又在每个 fetch 的Authorization头里手动读出来 → 安全风险高（XSS 可盗），不如用HttpOnly cookie+ 后端验证 - 用
localStorage存登录态并自己实现“过期”逻辑 → 容易因时钟误差或未清理导致状态不一致 - 在单页应用里频繁读写
localStorage做状态同步 → 应优先用 React/Vue 状态管理，存储只做持久化兜底
真正该纠结的不是“怎么选”，而是“这个数据到底需不需要离开当前页面上下文”。如果答案是否定的，连 localStorage 都不用碰。
