JavaScript操作Cookie通过document.cookie字符串接口实现，读写需手动拼接，受限于4KB大小、自动传输、XSS/CSRF风险；现代替代方案如localStorage、IndexedDB和HttpOnly Cookie各司其职，Cookie主要用于服务端身份识别与跨子域共享。
JavaScript 中操作 Cookie 主要是通过 document.cookie 这个字符串接口实现的，它既可读又可写，但语法原始、功能简陋。相比现代存储方案（如 localStorage、sessionStorage 和 HTTP-only + Secure Cookie 配合后端），Cookie 在安全性、容量、作用域和使用体验上都有明显差异。
Cookie 的基本操作：读、写、删都靠字符串拼接
Cookie 不是对象，也不是 API，而是一个受限制的字符串属性。每次读取 document.cookie 只能得到**当前域名下所有可读 Cookie 的键值对（用分号分隔）**；写入则必须手动拼接完整字符串，包括路径、过期时间等属性。
-
写入：设置一个带过期时间和路径的 Cookie：
document.cookie = "theme=dark; expires=Fri, 31 Dec 2027 23:59:59 GMT; path=/; secure; SameSite=Lax"; -
读取：需自己解析字符串，例如用
split(';')+trim()+split('=')提取指定 key： -
删除：本质是覆盖——把过期时间设为过去，且
path必须与写入时一致，否则删不掉：document.cookie = "theme=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/";
Cookie 的核心限制：大小、传输、安全属性不可绕过
每个 Cookie 最大 4KB，整个域名下通常最多 100–150 个（浏览器有差异）。更关键的是，它默认随每个 HTTP 请求自动发送到服务端——即使只是请求一张图片或一个 CSS 文件。这带来两个问题：
- 浪费带宽：大量无关请求携带冗余 Cookie 数据
- 安全风险：若未设
HttpOnly，前端 JS 可读写，易受 XSS 攻击窃取登录态；若未设Secure，HTTPS 页面可能被降级泄露 -
SameSite属性（Lax或Strict）用于缓解 CSRF，但需后端配合设置，JS 无法动态修改该属性
现代替代方案各司其职，不混用
前端本地存储已分化出明确分工：
立即学习“Java免费学习笔记（深入）”；
- localStorage / sessionStorage：纯前端、无自动网络传输、5MB 左右容量、仅字符串、无过期机制（需自行管理时间戳），适合存 UI 状态、缓存非敏感数据
- IndexedDB：结构化、异步、支持事务和大量数据（几十 MB+），适合离线应用、消息队列、复杂缓存
-
服务端 Session + HttpOnly Cookie：最推荐的用户身份方案——Session ID 存在
HttpOnly、Secure、SameSite的 Cookie 中，真实凭证只留在服务端，前端无法访问，大幅降低 XSS 泄露风险
什么时候还必须用 Cookie？
不是所有场景都能替代：
- 需要服务端识别身份（如登录态、CSRF Token）——必须靠 Cookie（尤其是
HttpOnly版本） - 跨子域共享数据（如
example.com和app.example.com）——可通过domain=.example.com实现，localStorage无法跨域 - 服务端渲染（SSR）首次响应需携带用户上下文（如语言、主题）——Cookie 是唯一能在首屏 HTML 中被服务端读取的客户端存储
基本上就这些。Cookie 没被淘汰，但它早已不是“前端存点东西”的首选；它是前后端协作的身份信使，不是前端的私人记事本。用对地方，才安全可靠。
