document.cookie 是最简但受限的 cookie 操作方式，需手动编码/解析；localstorage 更适合存非敏感结构化数据，二者分工明确：cookie 用于 http 传输与安全控制，localstorage 用于前端状态管理。
直接读写 document.cookie 是最简方式，但有严重限制
JavaScript 没有原生的 Cookie 类或封装 API，所有操作都通过 document.cookie 这个可读可写的字符串属性完成。它不是对象，不能用点语法取值，也不能直接赋值 JSON —— 赋值时必须是 key=value 格式，且多个键值对用分号加空格分隔。
常见错误现象：
- document.cookie = "user={name:'admin'}" 看似存了对象，实际只是把字符串 {name:'admin'} 当作 value 存了，后续读取无法自动解析
- 读取时 document.cookie 返回一整串，比如 "a=1; b=2; c=3"，不手动解析就拿不到单个值
- 忘记设置 path 或 domain，导致写入后在子路径下读不到
实操建议：
- 写入前务必 URL 编码 value：encodeURIComponent(value)
- 读取后需手动按 ; 分割 + = 拆解，推荐封装成 getCookie(name) 函数
- 设置有效期必须用 expires（UTC 时间字符串）或 max-age（秒数），二者选其一
- 若希望整个站点都能访问，显式加上 path=/
用 localStorage 替代 cookie 存非敏感结构化数据
只要不需要随 HTTP 请求自动发送、不涉及服务端鉴权，localStorage 是比 cookie 更合理的选择：容量更大（通常 5MB）、API 直观、支持任意字符串（包括 JSON）。
使用场景：
- 用户偏好设置（主题、语言）
- 表单草稿临时保存
- 前端路由状态缓存
实操建议：
- 存对象必须先 JSON.stringify()，取出来再 JSON.parse()
- localStorage.setItem('user', JSON.stringify({id: 123, name: 'Alice'}))
- const user = JSON.parse(localStorage.getItem('user') || 'null')（注意空值处理）
- 不要存敏感信息（如 token），因 XSS 可直接读取
- 修改后会触发同源下其他 tab 的 storage 事件，可监听同步状态
cookie 和 localStorage 的关键差异直接影响选型
它们根本不是替代关系，而是分工不同：
参数差异与影响：
- cookie 支持 HttpOnly（JS 无法读取，防 XSS）、Secure（仅 HTTPS 传输）、SameSite（防 CSRF）—— 这些是 localStorage 完全没有的
- localStorage 数据永不过期（除非手动清除），而 cookie 必须设 expires 或 max-age，否则是会话级（关闭浏览器即失效）
- cookie 大小限制约 4KB/条，localStorage 约 5MB/源，但大量 cookie 会拖慢每次请求（浏览器自动追加到 Header）
性能影响：
- 频繁读写 document.cookie 不影响主线程，但字符串拼接和正则解析成本略高
- localStorage 读写是同步阻塞的，大数据量（如 >1MB）可能卡顿，不适合高频操作
现代项目应优先考虑 localStorage + httpOnly cookie 组合
真实业务中，几乎不会只用其中一种。典型做法是：
- 认证凭证（如 session_id）走 httpOnly + Secure cookie，由后端签发、前端不可读
- 用户界面状态、配置项等存在 localStorage，前端完全掌控
- 若需跨域共享少量数据，localStorage 不行，得用 postMessage 或后端中转
容易被忽略的地方：
- document.cookie 写入时若漏掉 =，比如 document.cookie = "flag"，浏览器会当作删除该 key（值为空字符串）
- localStorage 在无痕模式下可能抛出 QuotaExceededError，需 try/catch 包裹
- Safari 对第三方上下文中的 localStorage 有严格限制（ITP 策略），部分 iOS 版本甚至禁用
