JavaScript操作Cookie需手动字符串解析，存在容量小、自动携带、无结构化API等缺陷；现代存储方案更适合作前端数据容器，但Cookie在服务端会话管理中不可替代。
JavaScript 通过 document.cookie 读写 Cookie，但它本质上是字符串拼接与解析，操作繁琐且缺乏原生结构支持。相比现代存储方案（如 localStorage、sessionStorage、IndexedDB），Cookie 在容量、性能、安全性与用途上存在明显局限。
如何用 JavaScript 操作 Cookie
Cookie 不是对象，而是以分号分隔的键值对字符串，需手动解析和拼接：
-
设置 Cookie：使用
document.cookie = "key=value; expires=...; path=/; domain=...; secure; HttpOnly"。注意：HttpOnly标志会禁止 JS 访问，只能由服务端设置；secure表示仅 HTTPS 下发送。 -
读取 Cookie：
document.cookie返回当前域下所有可读 Cookie 的字符串（不含HttpOnly），需自行按;和=拆解并解码（decodeURIComponent）。 -
删除 Cookie：将过期时间设为过去（如
expires=Thu, 01 Jan 1970 00:00:00 GMT），且path和domain必须与设置时一致，否则无法覆盖。
Cookie 的核心缺点
它不是为前端数据存储设计的，本质是 HTTP 请求/响应的附属机制：
-
大小受限：单个 Cookie 通常不超过 4KB，整个域名下总大小也有限（多数浏览器约 8KB），远小于
localStorage（通常 5–10MB）。 - 每次请求自动携带：只要路径匹配，Cookie 会在每个同域 HTTP 请求头中被发送（包括图片、脚本等静态资源），浪费带宽、拖慢请求速度，且无法按需控制。
-
无结构化 API：没有
setItem/getItem这类方法，增删改查全靠字符串操作，易出错；不支持直接存对象或数组，必须手动序列化。 -
安全模型复杂：依赖多个属性协同（
Secure、HttpOnly、SameSite）才能防范 XSS 和 CSRF，配置错误就可能暴露敏感信息或被滥用。
为什么现代存储更适合作为前端数据容器
它们专为客户端持久化设计，职责清晰、能力明确：
立即学习“Java免费学习笔记（深入）”；
-
localStorage和sessionStorage提供简单键值接口，支持较大容量，不参与网络传输，适合存用户偏好、表单草稿等非敏感状态。 -
IndexedDB支持事务、索引、大量结构化数据，适合离线应用、缓存复杂业务数据。 - 三者均受同源策略保护，API 统一，有事件通知（如
storage事件），且可通过 Service Worker 配合实现高级缓存策略。
Cookie 的不可替代场景
它仍有唯一价值：服务端身份识别与会话管理。因为只有 Cookie 能在每次请求中自动送达服务端，且支持 HttpOnly + Secure + SameSite=Strict 组合，是目前最稳妥的登录态传递方式。Token 存 localStorage 后手动带入请求头，仍需额外防 XSS；而 Cookie 可让敏感 token 对 JS 完全不可见。
