不该用 Cookie 存储非鉴权大资产，因其强制自动携带导致带宽浪费、性能下降与安全风险；受限于大小、结构及无粒度过期机制；且非鉴权数据本不应出现在请求头中；应改用 localStorage、sessionStorage、IndexedDB 或显式 API 同步。
不该用 Cookie 存储非鉴权大资产，核心原因在于：它会强制在每一次请求中自动携带，而这类数据既不需要服务端识别身份，也不该随每个请求传输——这直接造成带宽浪费、性能拖累和安全暴露面扩大。
一、Cookie 的“自动携带”不是功能，是约束
Cookie 的设计目标是会话跟踪，不是通用存储。浏览器只要匹配 domain + path + secure/httpOnly 等规则，就会无条件把它塞进每个请求头（哪怕你只是请求一张图片、一个 favicon 或一个静态 CSS 文件）。这种“不问用途、一律带上”的机制，对鉴权凭证（如 sessionid）合理，但对非鉴权的大资产（比如用户偏好配置、主题设置、多步骤表单草稿、长文本缓存）完全不匹配。
- 每次 HTML 页面请求，附带 2KB 的用户界面配置项 → 多余传输
- 每次加载 /api/v1/user/profile 图标，也捎上 4KB 的完整表单草稿 → 白耗带宽
- 静态资源（如 /static/js/main.js）请求同样携带全部 Cookie → 服务端无法忽略，CDN 也无法有效缓存
二、大小与结构限制让“大资产”存放很别扭
Cookie 单条上限约 4KB（含 name=value 及所有属性），且是纯文本键值对。若强行塞入 JSON 字符串、Base64 图片片段或序列化对象：
- 容易超限导致截断，解析失败
- 无法分片管理，更新某一项需重写整条 Cookie
- 没有原生过期粒度控制（不能单独让“草稿”过期，而保留“主题色”）
- 服务端每次都要解析整段字符串，增加 CPU 开销
三、“非鉴权”意味着它本不该出现在请求头里
鉴权信息（如 sessionid、token）需要服务端验证身份，所以必须出现在请求头中；但非鉴权数据（如 darkMode: true、lastSearch: "react hooks"）仅用于前端渲染或行为控制，服务端根本不需要、也不应该看到它。
- 放在 Cookie 中 → 浏览器自动发给后端 → 后端日志/监控可能意外记录敏感关键词
- 放在 localStorage 中 → 完全由前端读取使用 → 后端零感知，边界清晰
- 若需服务端参与（如同步多端状态），应走显式 API 调用，而非隐式携带
四、替代方案更精准、可控、可扩展
非鉴权大资产应按用途分流存储：
- 前端临时状态：用 sessionStorage（页面会话级）或内存变量（如 React state）
- 跨页面持久偏好：用 localStorage（支持 5–10MB，JSON 可读可查）
- 需服务端协同的草稿/缓存：存到 IndexedDB + 定时异步同步至后端接口
- 服务端托管配置：用用户专属配置表，通过 /api/config 显式拉取，按需加载
这些方式都规避了“自动携带”，也避免把客户端逻辑数据污染服务端通信链路。
