结论：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 到底该选哪个？
看生命周期需求——不是“哪个更高级”，而是“数据该活多久”。
立即学习“Java免费学习笔记（深入）”；
- 用
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，是浏览器安全底线。
