sessionStorage是仅限当前标签页的前端内存存储，关闭即销毁，不参与网络请求；Cookie通过HTTP头收发，服务端可控，用于身份认证等跨请求场景。
sessionStorage 是前端内存式存储，不发请求；Cookie 是 HTTP 头部携带的键值对
sessionStorage 完全运行在浏览器 JS 运行时环境中，数据只存在当前标签页的内存里，页面关闭即销毁。它不参与任何网络请求，document.cookie 读不到它，服务端也完全感知不到。而 Cookie 是由浏览器自动通过 Cookie 请求头发送给服务端的，服务端也能通过 Set-Cookie 响应头写入，属于客户端与服务端共管的通信凭证。
大小限制差异极大：sessionStorage 通常 5–10MB，Cookie 单个不超过 4KB 且总和建议 ≤4096 字节
实际可用容量取决于浏览器实现：
localStorage/sessionStorage 在 Chrome/Firefox 中普遍支持约 5MB～10MB（按字符串 UTF-16 字节计）；而 Cookie 每个 key=value 最多 4096 字节（含等号、分号等），且同域名下所有 Cookie 总大小被多数浏览器硬性限制在 4096 字节左右——超了可能被截断或丢弃。这意味着存一个 3KB 的用户配置对象到 sessionStorage 安全，但若塞进 Cookie，不仅挤占登录态空间，还可能让后续请求头膨胀、触发 Nginx 的
400 Bad Request（因 header 超限）。
生命周期与作用域完全不同：sessionStorage 绑定标签页，Cookie 可设 path/domain/expires
sessionStorage 的数据仅在当前 tab 生效，新开 tab 或恢复关闭的 tab（即使 URL 相同）都不可见；刷新页面保留，关闭 tab 即清空。而 Cookie 可通过属性精细控制：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
path=/admin：仅 /admin 下路径发送 -
domain=.example.com：子域共享（如 a.example.com 和 b.example.com） -
expires=Wed, 21 Oct 2027 07:28:00 GMT：持久化存储（否则为会话级，关浏览器即失）
auth_token），而 sessionStorage 更适合暂存表单草稿、筛选状态等纯前端上下文。
安全性机制不互通：HttpOnly/Cookie 无法被 JS 访问，sessionStorage 始终可被脚本读写
带 HttpOnly 标志的 Cookie 无法被 document.cookie 读取，有效防御 XSS 窃取 token；但 sessionStorage 没有此类保护，任何执行的 JS（包括第三方 script）都能 sessionStorage.getItem('key') 拿到全部内容。反过来，Cookie 不支持直接存复杂结构，必须序列化为字符串；而 sessionStorage 虽能存 JSON 字符串，但不能直接存对象或函数——
sessionStorage.setItem('user', JSON.stringify({id: 1, name: 'Alice'})); // ✅<br>sessionStorage.setItem('user', {id: 1, name: 'Alice'}); // ❌ 存进去是 '[object Object]'这点常被忽略，导致取出来无法解析。
立即学习“前端免费学习笔记（深入）”；
真正容易出问题的地方不在“选哪个”，而在混用：比如把 JWT 放 sessionStorage 以为更安全，却忘了它仍可被 XSS 劫持；或者用 Cookie 存大量 UI 配置，结果拖慢每次请求。关键不是容量或 API 差异，而是通信意图——需要服务端知道？走 Cookie；纯前端流程暂存？用 sessionStorage；要跨 tab 同步？那得换 localStorage 或 BroadcastChannel。
