4KB是Cookie因HTTP协议要求而定的头部传输限制，5MB是Web Storage为前端独立存储设定的本地容量配额；前者用于轻量会话标识且随请求发送，后者专为大体积前端数据设计、不参与网络传输。
5MB 和 4KB 不是随意定的数字，而是由浏览器内核对两类机制的底层实现方式决定的物理限制。
存储容量差异源于设计目标不同
Cookie 是 HTTP 协议的一部分，从诞生起就为“在请求头中轻量传递状态”服务。HTTP 规范建议单个 Cookie 值不超过 4096 字节（即 4KB），浏览器实际执行时还会预留字段开销（如 Domain、Path、Expires、Secure 等），导致有效载荷常低于 4095 字节。超出部分会被静默截断——你调用 document.cookie = "key=" + longStr 后查不到报错，但数据已丢失。
Web Storage（localStorage/sessionStorage）是 HTML5 为前端独立存数据而设的专用 API，不参与网络传输，浏览器为其单独分配本地磁盘/内存缓存区。主流浏览器默认配额为：
- Chrome：约 2.5–5MB（按源动态计算，受可用磁盘空间影响）
- Firefox / Opera：标准 5MB
- Edge / IE：最高支持 10MB
这个量级足够存一个含缩略图的用户配置 JSON、多页表单草稿，甚至小型离线资源包。
同域名下总量限制逻辑完全不同
Cookie 还受“数量+总长”双重约束：
- Chrome 最多允许同域 180 个 Cookie
- Firefox 约 150 个
- 一旦超限，新写入的 Cookie 直接被丢弃，无提示
Web Storage 没有条目数限制，只看总字节数。你可以存 1000 个键，只要所有 value 的 UTF-16 字符总长度未超配额，就完全合法。
为什么不能把大对象硬塞进 Cookie
假设你尝试用 Cookie 存一个 100KB 的用户设置对象：
- 它远超 4KB 上限，必然被截断
- 即使拆成多个 Cookie，也极易触达浏览器条数上限
- 每次页面请求都会把全部 Cookie 发往服务器，造成严重带宽浪费和首屏延迟
- 服务端无法区分哪些是必要会话标识，哪些是冗余前端状态
而 Web Storage 中同样数据只存在本地，JS 调用 localStorage.setItem("userConfig", JSON.stringify(obj)) 即可完整保存，读取时再 JSON.parse() 还原，全程不经过网络。
识别差异的实操判断法
遇到存储需求时，快速判断可依据三点：
- 是否必须随每次 HTTP 请求发给后端？→ 是 → 只能用 Cookie（且务必精简）
- 是否纯前端使用、体积可能超过几 KB？→ 是 → 应选 localStorage 或 sessionStorage
- 是否要支持 IE8+ 且无需大容量？→ 是 → 才考虑降级用 Cookie 模拟（不推荐）
本质上，4KB 是 HTTP 头部承载能力的工程妥协，5MB 是浏览器为前端应用划出的本地“私人仓库”——不是数值大小的问题，而是角色分工的硬边界。
