Web Storage 与 Cookie：从机制到应用的全方位对比

b. 网络流量（带宽浪费）

• Cookie： 每次你请求一个新的页面（或任何资源）的时候，Cookie 都会被自动附加在 HTTP 请求头中发送过去。如果 Cookie 有 2KB，页面有 100 个请求，就会产生 200KB 的额外流量，无形中浪费了带宽，增加了请求耗时。
• Web Storage： 数据仅保存在本地，绝不参与网络通信，不会增加任何 HTTP 请求的负担。

c. 作用域与跨域

• Cookie： 需要指定作用域（Domain 和 Path）。虽然可以设置主域名让子域共享，但出于安全考虑，不可以跨域调用（例如 a.com 无法读取 b.com 的 Cookie）。
• Web Storage： 遵循同源策略。协议、域名、端口必须完全一致才能访问，比 Cookie 的作用域限制更为严格和安全。

d. API 易用性

Web Storage： 拥有简单明了的 API，如 setItem，getItem，removeItem。

// Web Storage 操作（优雅）
localStorage.setItem('name', 'zhangsan');
const name = localStorage.getItem('name');
sessionStorage.setItem('key', 'value');

Cookie： 原生操作非常原始，开发者需要自己封装 setCookie，getCookie 方法去解析 document.cookie 字符串。

// 原生 Cookie 操作（繁琐）
document.cookie = "name=zhangsan; path=/";
function getCookie(name) {
    /* 需要自己写正则解析字符串 */
}

e. 设计初衷

• Cookie： 早期设计用于维持 HTTP 状态（因为 HTTP 是无状态的）。Cookie 的作用是与服务器进行交互，作为 HTTP 规范的一部分而存在。服务端可以写 Cookie，客户端也可以读。
• Web Storage： 纯粹为了解决客户端本地存储而生。它仅仅是为了在本地'存储'数据而生，没有任何与服务器自动通信的机制。

f. 历史兼容与封装

• 在 IE7、IE6 时代，浏览器有私有的 UserData 行为。通过简单的代码封装，可以将 UserData 的 API 模拟成 Web Storage 的接口，从而实现所有浏览器都支持 web storage 的假象。这体现了 Web Storage 在设计上对 API 规范化的追求。

4. 总结对比表

5. 应用场景建议

什么时候选 Cookie？

• 需要服务器识别用户状态（如 Session ID）。
• 需要实现子域名的单点登录（如 passport.baidu.com 和 tieba.baidu.com 共享登录态）。
• 数据量很小，且必须自动携带给后端。

什么时候选 Web Storage？

• localStorage： 适合存储长期不变的、与后端无关的数据。例如：网站主题、用户自定义的布局、大文本内容草稿。
• sessionStorage： 适合存储表单填写过程中的临时数据，防止刷新页面丢失；或者记录当前页面的浏览位置。

6. 结语

理解 Cookie 和 Web Storage 的区别，不仅仅是应对面试，更是写出高性能、低 Bug 应用的基础。

• 不要把大数据（如 Base64 图片、大 JSON）塞进 Cookie。
• 不要用 localStorage 存储敏感信息（如明文密码），因为它没有任何加密措施，且易受 XSS 攻击。
• 记得在需要服务器交互时，Cookie 依然是你最好的朋友；而在单纯客户端存储的场景下，拥抱 Web Storage 吧！