企业官网建设流程全解析

做前端时间久了，你会发现一个特别拧巴的事：明明浏览器给了我们好用的本地存储方案，可很多项目里，大家还是习惯把所有东西一股脑塞进Cookie里。登录态存Cookie、用户偏好存Cookie、购物车也存Cookie……搞得请求头越来越肥，每次网络传输都背着几十个字段的包裹。直到我接手一个老项目，被人诟病“明明就是个内部系统，每次请求却像搬家一样沉重”，我才下决心把整块存储逻辑从Cookie迁到了localStorage和sessionStorage上，顺便把这两个API彻底吃透。

这篇就聊聊我自己折腾Web Storage的完整实战记录。不吹不黑，把localStorage和sessionStorage的用法、跟Cookie的恩怨、封装技巧、安全边界都说清楚。适合刚接触前端存储的初学者，也适合那些想在项目里做存储方案改造、但一直没抽出时间动手的开发者。

1. 从Cookie的痛点说起：为什么前端存储要换思路

先说个可复现的小实验。打开你的开发者工具，在Console里随便往Cookie塞信息，比如用document.cookie = "demo=1"多塞几次，然后去Network面板看任何一个同源请求的Request Headers。你会看到Cookie这一行正在悄悄变长。这还只是本地开发，如果是在真实项目里，Cookie承载了登录态、埋点参数、甚至各种设置项，那请求头体积会相当可观。

1.1 Cookie的四宗罪

我总结过Cookie作为前端存储容器的四个问题，基本能解释为什么越来越多团队切换到了Web Storage。

第一，体积太小。单域名下Cookie总量被限制在4KB左右（不同浏览器略有差异），虽然实际开发中很少真的塞满4KB，但一旦超了，浏览器会选择丢弃部分Cookie，而且丢哪个行为并不完全可控。这个不可控是最恶心的。

第二，请求头默认会携带。Cookie的设计初衷是让服务器通过请求头识别用户状态，这是它的核心价值。但如果你只是想在浏览器本地存点数据，Cookie这个“每次自动带上”的特性反而是负担。多出来的流量在Wi-Fi环境感知不到，但在弱网、移动端场景下，每一KB都是白花花的加载时间。

第三，生命周期管理太原始。给Cookie设置过期时间是expires字段那一套UTC字符串格式，方法古早且容易踩坑。想删除一个Cookie，还得把过期时间调到过去、同时防止路径和domain不匹配造成的“删不掉”问题。我在项目里就见过为了删一个Cookie写了二十行兼容代码后遗症。

第四，数据类型被阉割。Cookie里只能存字符串，存对象得先JSON.stringify()，取的时候再JSON.parse()。这个倒也罢了，关键是稍不留神忘记转换，排查半天才发现问题出在类型上。

1.2 Web Storage到底解决了什么

localStorage和sessionStorage属于HTML5的Web Storage规范，它们的核心特点是“本地存储，不发请求”。也就是说，写入的数据保存在浏览器中，网络请求不会自动携带，你需要什么数据、什么时候把数据传给服务器，完全由业务代码决定。

这个设计思路的变化很关键：Cookie代表的是“服务器视角的客户端状态存储”，而Web Storage代表的是“浏览器视角的客户端数据存储”。当一个项目主要做数据持久化和本地缓存时，后者明显更顺手。

我之前做的一个协作工具里，用户的列表视图偏好、上次筛选条件、侧边栏折叠状态，全部从Cookie迁到了localStorage。迁移完成后，同一接口的请求头从原来的一百多字节降到了几十字节，虽然数字不大，但胜在干净通透。而且代码量反而变少了，因为不再需要那些花里胡哨的Cookie读写兼容逻辑。

2. Web Storage核心API：十分钟掌握增删改查

先说一个很多初学者会混淆的点：localStorage和sessionStorage这两个对象暴露的方法完全一样，不用记两套API。它们只是在生命周期和作用域上有区别，后面会细说。这里先以localStorage为主，把基础操作过一遍。

2.1 四个基础方法一网打尽

增改和查询用的是setItem()和getItem()。修改和新增在接口层面没有区分，同一个key重复写入，后者覆盖前者。

// 存入数据 localStorage.setItem('username', 'zhangsan'); // 读取数据 const username = localStorage.getItem('username'); console.log(username); // 输出：zhangsan

删除分两种：removeItem()删单条，clear()清空所有。clear()这个操作很危险，建议只在“退出登录”这种整体性场景使用，平时尽量用removeItem精准删除。

// 删除指定key localStorage.removeItem('username'); // 清空当前域名下的全部本地存储 localStorage.clear();

还有一个不怎么起眼但很实用的key()方法，配合length属性可以遍历当前存储空间里的所有数据。这在调试阶段很有用，比如你想看看这个域名下到底存了哪些key，在Console里跑一个循环就够了。

// 遍历所有key和value for (let i = 0; i < localStorage.length; i++) { const key = localStorage.key(i); const value = localStorage.getItem(key); console.log(key, value); }

如果直接给localStorage对象挂属性赋值的写法，比如localStorage.username = 'zhangsan'，也能工作，但我不推荐。因为这种写法在key名带特殊字符时会出问题，而且它绕过了Web Storage规范的标准API路径，容易在代码审查和生产环境调试时产生认知偏差。统一用setItem/getItem这一套，所有人都好维护。

2.2 sessionStorage的语义和边界

sessionStorage的API完全一致，但生命周期和localStorage截然不同。它本质上是一个“标签页级别的存储”：数据在标签页关闭的瞬间被清空，并且它不允许在不同标签页之间共享数据。

好多人第一次用sessionStorage时会有个误解：以为它是“会话级别的存储”，关闭浏览器才清空。不对，它比会话更小粒度——同一个浏览器窗口里开两个标签页访问同一个网站，A标签页写入sessionStorage的数据，B标签页完全读不到。这是由它的设计目标决定的：隔离同一个网站在不同标签页里的独立状态。

这在什么场景有意义呢？最典型的是数据填写中途的草稿恢复。比如用户在一个多步骤表单里填了一半，不小心刷新了页面。刷新不会关闭标签页，sessionStorage里的数据还在，页面加载后可以重新回填。但如果你开两个标签页同时填同一份表单，两个标签页互不干扰，这才是符合直觉的交互。

2.3 实操：给搜索框加一个最近的搜索记录

基础API讲完，落地一个小例子收收尾。给站内搜索框加“最近搜索”功能，点击搜索时存关键词，下拉框里展示最近的十条记录。

function addSearchKeyword(keyword) { const key = 'search_history'; const history = JSON.parse(localStorage.getItem(key) || '[]'); // 去重 const filtered = history.filter(item => item !== keyword); // 插到最前面 filtered.unshift(keyword); // 只保留10条 const result = filtered.slice(0, 10); localStorage.setItem(key, JSON.stringify(result)); return result; }

这里有个小细节：把JSON.parse(localStorage.getItem(key) || '[]')写在一起，是因为getItem取不到值时返回null，而JSON.parse(null)会直接报错。用|| '[]'做了一个空值兜底，这个写法在Web Storage场景里非常高频，建议直接记住。

3. localStorage与sessionStorage：兄弟俩的差异与选型

两个API长得像，用法一样，但在实际项目中选型如果选错了，会出现一些非常隐蔽的bug。比如用户在一个标签页改了个性化设置，打开另一个标签页发现没同步，顿时觉得产品“有毛病”。所以要搞清楚它俩在生命周期和作用域上的差别。

3.1 核心差异对照表

我整理了一张常用差异对照表，基本覆盖了日常开发需要用到的全部关键点。

刷新页面这里要特别说明，sessionStorage在刷新时数据不会丢，很多人误以为刷新就没，实际上刷新只是重新加载文档，只要标签页没关闭，存储数据就一直在。只有把这个标签页整个关掉，sessionStorage才彻底清空。

3.2 跨标签页数据的读写策略

因为sessionStorage不跨标签页，而localStorage跨标签页，所以会引发一个选型问题：如果用户开了两个标签页使用同一个应用，你希望数据是“各管各的”还是“全局一致的”？

我的经验是：模板类数据、系统全局配置用localStorage；临时草稿、当前操作上下文用sessionStorage。比如一个后台管理系统，侧边栏折叠状态这种全局UI偏好，用localStorage存——用户在一个标签页里折叠了侧边栏，打开另一个标签页也应该是折叠的；而用户正在编辑但还没提交的表单草稿，用sessionStorage存——他甚至可能同时在两个标签页里编辑两份不同的内容，让它们各自保存各自的状态，反而更合理。

还有一个比较深的坑：localStorage是跨标签页共享的，但它不会像多进程系统那样主动推送变更给其他标签页。如果一个应用在多个标签页同时运行时，一个页面改了localStorage，另一个页面是不会自动感知的。这时候需要配合window.addEventListener('storage', handler)来监听变化。这个事件只在其他标签页修改localStorage时触发，当前标签页自己改自己不触发。记得有一次我在项目里做用户信息同步，改了localStorage之后另外的标签页界面不刷新，排查了半天才发现需要自己监听storage事件后手动触发更新逻辑。

3.3 为什么sessionStorage不能跨标签页

从浏览器设计角度看，sessionStorage的“会话”绑定的是标签页（有时也跟标签页的复制行为有关）。这是刻意的设计，而不是缺陷。它的目标是隔离并发上下文——如果没有这个隔离，两个同时打开的标签页互相覆盖数据，草稿保存功能就彻底废了。

所以选型的时候不要试图“克服”sessionStorage的隔离性。如果确实需要跨标签页共享数据，就应该去用localStorage；如果有多个标签页并行且数据必须隔离，就用sessionStorage。产品逻辑决定技术选型，而不是反过来。

4. 进阶封装：一套带过期时间、命名空间和JSON序列化的storage工具

原生API很简单，但放到真实项目里，几个短板就暴露出来了。最明显的一个：localStorage没有过期时间概念。存进去的数据，如果不手动清除，永远都在。可实际业务里“记住我的设置七天”这种需求太常见了，你总不能自己写个定时器去轮询清理。第二个短板是：每个key都是全局平铺的，项目一复杂，整个域名下的key会乱成一锅粥。

所以实战中我一般会自己封装一层工具，让localStorage具备“接近产品需求”的能力。下面是我在多个项目里反复打磨之后相对稳定的一版，带过期时间、命名空间、JSON序列化和按前缀清理。

4.1 为什么原生API不够用

先看一个原生API处理“七天有效期”的笨办法：存数据的时候，额外存一个key + '_expires'字段放时间戳，读取的时候手动比较。每次读取都要先取时间戳再取数据再判断，代码冗余不说，还容易漏掉过期判断。

更麻烦的是命名。不同功能模块如果不约好key的命名规范，很容易出现A模块写入了user_id，B模块也往user_id里写数据的冲突。localStorage没有命名空间隔离，同一个域名下所有key共享一个存储空间。不封装一层的话，就只能靠开发者的自觉，这实在不靠谱。

4.2 封装带过期时间的存储工具

我的封装思路很朴素：数据存储时用一个统一的结构包一层，里面除了业务数据外，附带一个过期时间戳。读取时判断当前时间是否超过过期时间，超过了就自动删除并返回null。

const storage = { // data 可以是任意可JSON序列化的对象 set(key, data, expireSeconds = 0) { const payload = { data, expireAt: expireSeconds > 0 ? Date.now() + expireSeconds * 1000 : 0 }; localStorage.setItem(key, JSON.stringify(payload)); }, get(key) { const raw = localStorage.getItem(key); if (!raw) return null; try { const payload = JSON.parse(raw); // 兼容旧数据：如果没有expireAt字段，视为永不过期 if (payload.expireAt && Date.now() > payload.expireAt) { localStorage.removeItem(key); return null; } return payload.data; } catch (e) { // 解析失败说明数据被改坏或格式不兼容，直接删掉避免反复报错 localStorage.removeItem(key); return null; } }, remove(key) { localStorage.removeItem(key); } };

用的时候就很舒服了。比如记住用户的登录态，设定7天过期：

// 登录成功后写入，7天秒数 = 7 * 24 * 60 * 60 storage.set('auth_token', { token: 'xxx', userId: 101 }, 7 * 24 * 60 * 60); // 下次打开页面读取 const auth = storage.get('auth_token'); if (auth) { // 未过期，正常使用 } else { // 已过期或不存在，跳转登录 }

这段封装注意两点。第一，expireAt在存入时就已经算好，读取时只需要和当前时间比较，不需要再换算，效率高；第二，get的时候如果发现过期，顺手就把这条数据删了——这个惰性删除避免了定时器，也不会留垃圾数据，是我个人很推荐的做法。

4.3 命名空间与按id删除数据

如果没有命名空间，不同模块之间的key容易撞车。我的方案是加一个前缀，统一成“模块名:业务名”的形式。

比如用户模块的用户信息key就是user:profile，购物车模块是cart:list。这样一眼就知道数据归属，而且还能实现按前缀批量删除：遍历所有key，把符合指定前缀的key全部removeItem。

// 根据业务前缀删除localStorage数据 function removeByPrefix(prefix) { const keys = []; for (let i = 0; i < localStorage.length; i++) { const key = localStorage.key(i); if (key.startsWith(prefix)) { keys.push(key); } } keys.forEach(key => localStorage.removeItem(key)); } // 示例：清除所有用户相关的本地数据 removeByPrefix('user:');

这个小函数在“退出登录”场景非常实用。一个系统的本地数据可能有几十个key，如果分散在不同模块里，挨个removeItem容易漏，全量clear又太暴力。按前缀精准清理是最舒服的方案。这也回应了不少人常搜的一个问题：“如何根据id删除localStorage的数据”——本质上就是给每条数据的key设计一个可以回溯的规则，然后用前缀匹配去删。

4.4 处理JSON序列化的边界情况

Web Storage的API设计里只允许存字符串。所以存对象必须手动序列化，读出来再反序列化。我的封装里已经在set和get阶段自动做了这两件事，业务代码可以完全无感。但有一个边界情况容易忽略：存undefined或者函数这类不能被JSON序列化的值，JSON.stringify会直接丢弃或者返回undefined，存进去再读出来就是一个null，和你预期不符。

所以封装里最好对特殊值做个兜底。我习惯在set的时候加一个拦截：如果value是undefined或者function，直接提示开发者换用别的方案，绝不entity入库。

set(key, data, expireSeconds = 0) { if (data === undefined || typeof data === 'function') { console.warn(`storage.set: ${key} 的值无法被JSON序列化，写入已取消`); return; } // ... }

这种放在根上的防御性代码，第一眼看觉得多此一举，但团队大了以后，它反而能防止很多“为什么存进去读出来不一样”的幽灵问题。

5. 安全边界与常见误区：localStorage不是保险柜

说句实在话，Web Storage最容易被高估的点是“安全”。很多开发者把用户token、角色权限、甚至明文密码直接写进localStorage，觉得“存在本地，别人看不到”。但localStorage的一大特性是：任何在同源页面下运行的JavaScript都能直接读取和修改它。也就是说，哪怕只是一个XSS注入的小漏洞，攻击者都能在浏览器控制台里把你的localStorage翻个底朝天。

5.1 localStorage在控制台里是全透明的

这一条我在第4节封装的场景里也悄悄提过——用localStorage.key遍历一下，整个域名下的存储内容全部看得清清楚楚。你打开一个网站的开发者工具，切到Application面板，点开Local Storage，所有key和value都明文躺在那里。

这意味着两件事。第一，调试确实方便，想看一眼存储状态只需要点几下鼠标；第二，任何能在这个页面执行脚本的人，也具备同样的读取能力。所以千万不要把真正敏感的东西放进去。

做权限控制的时候，比较稳妥的做法是：核心的登录凭证建议仍然放在服务端控制的HttpOnly Cookie里，让JavaScript完全没有办法读取，从根上断掉XSS窃取凭证的可能。localStorage更适合去放“丢了也不致命”的数据，比如用户的界面偏好、主题颜色、布局设置、历史搜索记录这些。

5.2 这些数据千万别放进localStorage

根据我自己的踩坑经验，至少这几类数据不该放localStorage：

写到这里要特别强调一下：localStorage的数据虽然不能被其他网站跨域读取，但在同源页面的脚本攻击面前基本是裸奔的。关键逻辑必须依赖服务端校验，前端本地存储的任何内容都只能当作“展示用的缓存”，不能当作“权威数据源”。

5.3 Cookie也没那么糟糕：什么时候该回头用Cookie

说了半天告别Cookie，但其实Cookie也有Web Storage替代不了的能力。最典型的就是HttpOnly属性。所有通过JavaScript存储的方案都逃不开XSS读取风险，而HttpOnly Cookie是浏览器层面直接接管，脚本完全拿不到，这是Web Storage做不到的身份证级隔离。

另一个场景是服务端会话管理。传统模式下后端需要靠Cookie里的SessionID识别用户。你把SessionID搬进localStorage，那就得每次请求都手动在Authorization头里带上，同时还得自己维护过期和续期逻辑，麻烦不说，反而更容易出错。所以我的建议一直是：能用Service Worker或后端Session管理的敏感会话数据，继续交给Cookie；纯粹是前端UI状态、偏好、缓存类的数据，交给Web Storage。两个不是替代关系，各管一段。

6. 从Cookie迁到localStorage：一次真实项目改造记录

理论聊完了，给你看一个我实际做过的小改造。项目是个内部数据看板，登录后用户需要设置默认的时间范围、图表类型、表格密度等偏好。最早全部存在Cookie里，每次进入系统读取、修改偏好时更新Cookie。问题在于，内部系统SPA的请求本来就多，每次请求都自动带上这些偏好的Cookie，做了很多无用传输。

6.1 迁移的具体步骤

第一步，盘点Cookie里哪些数据属于“纯前端偏好”，哪些属于“服务端会话数据”。偏好类数据主要就是那三五个设置项，而真正的会话凭证是单独的会话Cookie。明确之后，偏好类数据全部迁到localStorage，会话Cookie保持不动。

第二步，封装一层偏好读取工具。因为老代码读取偏好时用的是Cookie工具函数，我不想改动所有业务调用点，就封装了一个适配层：读偏好的函数优先从localStorage读，读不到时再回退到Cookie里读旧值。这个兼容策略很重要，可以让改造平滑落地，不至于出现用户升级后偏好全丢的情况。

第三步，写入偏好时，同步清理旧Cookie。用户改了偏好，新值写入localStorage，同时把这个偏好对应的Cookie删掉，保证存量用户逐步完成数据迁移。删Cookie还碰到了前面说的path匹配问题，检查之后发现有个偏好Cookie原来设置在/路径下，删除的时候必须带上path=/参数才删得干净。

6.2 兼容性与降级策略

虽然现在的主流浏览器对Web Storage支持已经很完善，但还有两类边缘情况值得注意。第一类是隐私模式，有些浏览器的隐私模式可能会禁用localStorage的持久化写入，代码跑起来不报错，但刷新后数据没了。加上这个降级逻辑：写入时先试探性写一条测试数据，读回来看看是否一致，不一致就自动降级为“仅内存存储”模式。

let memoryStorage = {}; function safeStorageSet(key, value) { try { localStorage.setItem(key, value); } catch (e) { // 降级为内存存储 memoryStorage[key] = value; } }

第二类是旧系统里残留的“脏数据”。改造过程中我们发现有一个历史版本的偏好key命名是view_type，新版本改成了dashboard:view_type，老用户的localStorage里还留着旧key。为了不让这些过期数据干扰统计和埋点，我在适配层里加了一个读取逻辑：新key没数据时，自动检查旧key，读到了就迁移到新key并删除旧key。

改造完的实际收益，从Network面板看最直观：同样的页面加载，请求头里的Cookie长度从原来的一百多字节减少到只有会话凭证的几十字节。数值不大，意义不浅——至少说明本地浏览器存储的各司其职了。

6.3 测试Web Storage代码的小技巧

测试存储逻辑，我一般分三层。第一层用浏览器的Application面板手动改值。比如把某个key的expireAt时间戳改成过去的时间点，然后刷新页面看代码能否正确清除过期数据。第二层用Console直接调API模拟不同业务路径。第三层是自动化测试里把localStorage封装成可注入的假对象，业务代码不直接引用localStorage全局对象，而是通过storage工具的实例访问，这样测试时就能传一个mock对象进去，方便断言各种边界逻辑。

这里的核心思路是：业务代码不要跟浏览器API耦合得太死，通过自己封装的那一层storage工具来沟通。既能在封装层统一加日志、加过期规则，也方便在测试环境和未来的多端场景里替换实现。

说到底，localStorage和sessionStorage都不复杂，难的是在真实项目里找到合适的使用边界。我的体会是：把“服务端需要验证的数据”和“客户端自己用的数据”分清楚，选型就不会纠结。存储这件事，宜少不宜多，宜清晰不宜散乱，把最少的必要数据放在最合适的地方，才是成熟的前端存储实践。