17370845950

结论：Cookie需用js-cookie等库操作，localStorage/sessionStorage存对象必须JSON.stringify()和JSON.parse()。因document.cookie是分号分隔字符串，原生解析易错；二者仅支持字符串，存对象会变"[object Object]"；localStorage跨标签共享且持久，sessionStorage仅单标签有效且关闭即清空。

直接说结论：Cookie 要手动解析 document.cookie，不推荐原生操作；localStorage 和 sessionStorage 用 setItem()/getItem() 就行，但必须注意——它们只存字符串，对象要 JSON.stringify()，取出来得 JSON.parse()，否则拿不到

为什么别手写 Cookie 读写逻辑？

原生 document.cookie 是个“怪东西”：它不是对象，也不是数组，而是一长串用分号+空格拼起来的键值对字符串（比如 "a=1; b=2; c=3"），没有内置方法拆解。你得自己用 split('; ')、indexOf('=') 去切，还要处理 URL 编码、重复 key、作用域匹配……极易出错。

• 常见错误现象：document.cookie = "user=john" 看似设了，但再读 document.cookie 却发现多了其他项，甚至根本读不到刚写的值（因为没设 path=/ 或跨域/HttpOnly 拦截）
• 真正该做的：用 js-cookie 这类成熟库，一行搞定：

  Cookie.set('token', 'abc123', { expires: 7, path: '/' })

• 安全红线：如果后端设了 HttpOnly，前端 JS 根本读不到这个 Cookie（document.cookie 里不出现），这是故意设计，不是 bug

localStorage.setItem() 存对象为啥取出来是 "[object Object]"？

因为 localStorage（和 sessionStorage）底层只接受字符串作为值。你传个对象，JS 自动调 toString() → 得到 "[object Object]"，存进去的就是这六个字符。

• 正确做法：存之前 JSON.stringify()，取之后 JSON.parse()
• 实操示例：

  localStorage.setItem('user', JSON.stringify({ name: 'Alice', age: 28 }));
  const user = JSON.parse(localStorage.getItem('user')); // → { name: 'Alice', age: 28 }

• 容易踩的坑：如果存的字符串本身不是合法 JSON（比如中间有未转义的引号），JSON.parse() 会直接报错 SyntaxError，建议加 try/catch
• 兼容性注意：IE8+ 支持，但隐私模式下部分浏览器（如 Safari）会拒绝写入，setItem 可能抛出 QuotaExceededError

localStorage 和 sessionStorage 到底该选哪个？

看生命周期需求——不是“哪个更高级”，而是“数据该活多久”。

• 用 localStorage：用户关掉浏览器、重启电脑后还要存在的数据，比如暗黑模式开关、语言偏好、长期缓存的配置项
• 用 sessionStorage：仅当前标签页内有效，关掉就清空。典型场景：

  // 表单草稿（用户填一半关掉，再开新标签不恢复）
  sessionStorage.setItem('draft', '今天要完成文档...');
  
  // 页面跳转传参（避免暴露在 URL 里）
  sessionStorage.setItem('fromListId', '123');
  location.href = '/detail'; // 在 detail 页面读取

• 关键区别：同一域名下，localStorage 所有标签页共享；sessionStorage 每个标签页完全隔离，哪怕地址一样也不互通
• 别指望它们“自动过期”：两者都不支持 TTL（time-to-live），要实现过期，得自己存时间戳 + 读取时判断

最常被忽略的一点：同源策略是硬限制。协议、域名、端口三者必须完全一致，https://a.com 和 http://a.com 之间，localhost:3000 和 localhost:8080 之间，数据完全不互通——这不是 bug，是浏览器安全底线。