cookie 未被废弃但用途收窄，仅适用于同源、小体积、需服务端参与的会话标识；因是分号分隔字符串协议，读写需手动解析转义，易出错且易触发安全策略。
Cookie 在现代 Web 开发中依然存在，但直接用 document.cookie 手动操作已不推荐；它没被废弃，但用途被大幅收窄——仅适用于同源、小体积、需服务端参与的会话标识或少量状态同步。
为什么 document.cookie 写起来又难又容易出错？
它不是对象，也不是 API，而是一条用分号分隔的字符串协议。读写都要手动拼接、解析、转义，稍有不慎就丢数据或触发安全策略。
- 写入时漏
path=/或SameSite=Lax，可能导致 Cookie 在子路径或跨站请求中不可见 - 值含空格、分号、逗号等字符未
encodeURIComponent()，会导致截断（document.cookie = "a=b c"实际只存了a=b） - 读取时要自己
.split('; ')+.find()+decodeURIComponent()，没有内置方法
document.cookie = "token=abc123; path=/; HttpOnly; Secure; SameSite=Lax"; // 正确写法示例 // 但注意：HttpOnly 标志会让 JS 完全读不到这个 Cookie —— 这是设计，不是 bug
什么场景下还必须用 Cookie？
当你的需求同时满足以下三点时，Cookie 仍是不可替代的：
- 需要浏览器在每次 HTTP 请求中自动带上（比如后端鉴权用的
sessionid） - 需要跨页面/跨 tab 共享（
localStorage无法在 iframe 跨域时访问，而 Cookie 可配合withCredentials发送） - 需要服务端控制生命周期和作用域（如设置
Max-Age、Domain、Secure）
典型例子：fetch('/api/user', { credentials: 'include' }) 能自动携带登录态 Cookie；而 localStorage 里的 token 必须手动加到 Authorization header。
立即学习“Java免费学习笔记（深入）”；
替代方案怎么选？别盲目迁移到 localStorage 或 IndexedDB
不是所有“存点数据”的需求都适合换方案。关键看数据是否需要服务端参与、是否敏感、是否需持久化：
- 纯前端状态（如暗黑模式开关、折叠菜单）→
localStorage或useState+useEffect持久化更简单 - 敏感凭证（JWT、API key）→ 不该存在
document.cookie（除非HttpOnly），更不该放localStorage（XSS 可盗） - 大量结构化数据 →
IndexedDB，但 Cookie 最大仅 4KB，且每次请求都携带，带宽浪费严重
注意：localStorage 是同源限制，但不区分协议或端口；Cookie 的 Domain 和 SameSite 控制更细，也更易误配。
现代开发中真正该做的：封装 + 限制 + 监控
如果你确实要用 Cookie（比如维护遗留系统或对接老后端），不要裸写 document.cookie。至少做三件事：
- 封装一个
setCookie(name, value, options)函数，自动处理encodeURIComponent、path默认值、SameSite合理 fallback - 禁止在 Cookie 中存用户输入、长文本、JSON 字符串（体积和解析风险双高）
- 用 DevTools → Application → Cookies 面板验证实际写入值，特别注意
Size列是否超 4KB，HttpOnly是否影响 JS 读取逻辑
Cookie 的复杂性不在语法，而在它横跨客户端、网络层、服务端三端的隐式契约。少用、慎用、封装用，比争论“要不要用”更重要。
