你有没有想过：为什么关掉浏览器再打开，很多网站还认识你；而有些网页一刷新，刚才填的表单就没了？答案藏在浏览器提供的几种"存储机制"里。Cookie、localStorage、sessionStorage 各管一段，搞混它们是用不好前端状态的第一步。

一、Cookie：最老资格，跟着请求走

Cookie 是资格最老的存储，诞生于上世纪九十年代。它的特殊之处在于：每次浏览器向同域服务器发请求，都会自动把相关 Cookie 带上。这让服务器能识别"这次请求还是刚才那个用户"，登录状态因此得以保持。

但 Cookie 也有明显短板：容量很小（通常 4KB 上下），且每次请求都传输，多了就拖慢速度。它适合存"身份凭证"这类小而必须随请求走的数据，不适合存大块业务数据。

二、localStorage：关掉浏览器也在

localStorage 是 HTML5 引入的"纯本地"存储，容量大得多（一般 5MB 起），而且持久——除非代码主动删除或用户清缓存，否则关电脑再开它都还在。它不随请求发往服务器，纯粹给前端自己用。

适合放什么？用户偏好设置（深色模式开关）、离线草稿、不敏感的本地缓存。不适合放密码、token 这类敏感信息——它对所有脚本可读，一旦页面被注入恶意代码就会泄露。

三、sessionStorage：标签页级的临时记忆

sessionStorage 和 localStorage 用法几乎一样，唯独寿命不同：它只在"当前标签页会话"内有效。你关掉这个标签页，数据就没了；开一个新标签页，即使是同一个网站，也读不到另一个标签的数据。

它非常适合存"临时工作态"：比如多步骤表单填到第二步，刷新页面不该丢，但关掉就不必保留。用 sessionStorage 既不会污染 localStorage 的长期空间，也避免了用户重开页面看到陈旧草稿。

四、数据怎么存进去

这些存储基本只认字符串。你想存一个对象，得先序列化成 JSON 字符串；取出来再解析回对象。手写容易出错，用JSON 格式化先整理好结构，再存，可读性会好很多。

另外，有些数据需要在 URL 里传递或存储，可能包含特殊字符。用URL 编码处理后再放，能避免截断和解析错误。涉及二进制或需要文本化的场景，Base64 转换也常用于把数据塞进只认文本的通道——记住它只是编码，不是加密。

五、安全底线

无论哪种存储，都运行在用户浏览器里，本质上"用户和任何能注入脚本的人都能读到"。所以：敏感凭证别明文存前端；对用户输入做转义防止 XSS；重要操作的最终校验必须放回服务器。存储机制只是工具，安全模型得自己搭。

小结

三种存储对应三种寿命：Cookie 随请求走、管身份；localStorage 持久、管偏好；sessionStorage 随标签页生灭、管临时态。选谁，取决于"这段数据该活多久、该不该发给服务器"。理解这三者的边界，前端状态管理会一下子清晰起来。