前端“预存”：那些被你忽略的性能加速器
先说说啥是前端“预存”？其实就是提前把用户可能用到的数据、资源“存”在本地，等用户需要时直接从本地读取，不用再慢悠悠地从服务器请求。就像你出门前把钥匙、手机提前放进口袋，要用时随手就能拿到，不用临时翻箱倒柜。去年帮朋友的工具类网站做优化，他们的首页有个城市选择器，每次打开都要请求全国城市数据，3G网络下要等3秒多，用户吐槽“还没选城市呢就想关网页了”。后来我们把城市数据“预存”进localStorage，用户第一次加载后数据就存在本地，第二次打开直接读取，加载时间从3秒压到了0.2秒不到，3个月后页面停留时长涨了得40%。
前端“预存”常用的技术主要有四类，但很多人只知道前两种，其实后两种才是性能优化高手的秘密武器👇
第一种最基础的是localStorage/sessionStorage本地存储，可以存字符串格式的数据，容量5MB左右(不同浏览器略有差异)。比如你开发的电商网站，用户选择过的收货地址、筛选条件，可以存进localStorage，下次用户访问直接调出来预填好，体验感立马上升。不过要注意，localStorage是永久存储(除非手动清除)，sessionStorage只在当前会话有效，关了浏览器就没了，所以存临时数据用sessionStorage更合适，比如表单填写到一半用户刷新页面，用sessionStorage存一下，刷新后还能恢复内容，这个小细节能减少很多用户流失。
第二种是HTTP缓存，也就是浏览器自带的缓存机制，分强缓存(Expires/Cache-Control)和协商缓存(Last-Modified/ETag)。简单说就是让浏览器记住“这个资源我之前见过，不用再下载了”。去年我接手一个企业官网，发现他们的CSS、JS文件每次打开都重新请求，一问才知道开发时为了方便调试关了缓存，上线忘了改回来。后来帮他们配置了Cache-Control: max-age=31536000(缓存1年)，再配合文件指纹(比如style.v2.css)，用户第二次访问时静态资源直接从缓存加载，首页加载速度从5秒降到1.8秒，服务器请求量也少了60%。
第三种是Service Worker缓存，这个就高级点了，相当于在浏览器和服务器之间加了个“代理”，能拦截请求、自主决定从缓存还是服务器拿资源，甚至离线时也能显示页面。之前给一个新闻类APP做H5页面，用户反馈“地铁里没网就打不开”，我们用Service Worker把首页新闻列表和图片提前缓存下来，没网时用户照样能看之前加载过的内容，用户留存率一下涨了25%。不过Service Worker有个坑，必须在HTTPS环境下运行(本地localhost除外)，开发时得注意这点。
第四种是IndexedDB，适合存大量结构化数据，比如用户的历史浏览记录、离线表单数据，容量比localStorage大得多(一般不少于250MB)。之前帮一个医疗类网站做优化，他们需要存用户的健康记录，localStorage存不下还容易丢，换成IndexedDB后不仅存得多了，还支持事务和索引查询，查历史记录比之前快了3倍。
可能你会说“这么多技术，我该用哪个？”其实记住一个原则：小数据用localStorage/sessionStorage，静态资源用HTTP缓存，需要离线功能用Service Worker，大量结构化数据用IndexedDB。去年我给一个教育类网站做咨询，他们把所有数据都堆进localStorage，结果存了10MB内容，浏览器直接报错“超出存储限制”，后来按这个原则分类存储，问题立马解决。Google Web.dev上有篇文章也提到，合理的资源缓存策略能让页面加载速度提升40%-60%，这可不是吹牛，是有真实数据支撑的。
前端“预存”避坑指南：别让好心办了坏事
虽说“预存”能帮我们提升性能，但用不好反而会挖坑。就像你预存了一堆零食，结果过期了还没吃，不仅浪费钱还占地方。前端“预存”也是一个道理，我见过太多项目因为没避坑，反而让用户体验更差了。
第一个大坑是“过度预存”。之前合作过一个电商项目，开发为了让商品详情页加载快，把整个商品库数据(几万个SKU)都预存进localStorage，结果用户第一次访问要下载5MB的数据，页面直接卡崩。其实用户每次最多看几个商品，预存当前分类下的前20个就够了，剩下的按需加载。这里有个小技巧：用“预存优先级”判断，用户当前页面的核心数据(比如商品基本信息)优先存，次要数据(比如评论、相关推荐)延迟存，非核心数据(比如历史价格)不预存。
第二个坑是“数据过期”。想象一下，用户上周预存的商品价格是100元，今天打开页面看到的还是100元，结果点进去发现实际卖120元，肯定会觉得被欺骗了。这就是没处理好“预存数据新鲜度”的问题。我一般会给预存数据加个“有效期”，比如在localStorage存数据时，顺便存个时间戳，读取时判断“现在时间-存储时间”是否超过有效期(比如1小时)，超了就重新请求服务器。之前帮一个生鲜网站做优化，他们的商品价格变动快，我们把有效期设为30分钟，既保证了数据新鲜，又减少了60%的请求量。
第三个坑是“安全隐患”。localStorage里的数据是明文存储的，随便打开浏览器控制台就能看到，如果你把用户密码、token这些敏感信息存进去，等于把钥匙插在门上。去年有个理财类APP被曝安全漏洞，就是因为开发把用户的银行卡信息存进了localStorage，被黑客轻易获取。正确的做法是：敏感数据绝对不存本地，非要存的话先用AES加密(比如用crypto-js库)，再存进去。MDN文档里明确提醒：“localStorage不应用于存储敏感信息”，这个一定要记牢。
第四个坑是“忽略存储限制”。不同浏览器对localStorage的容量限制不一样，比如Safari是2.5MB，Chrome是5MB，超出了会报错。之前帮一个工具网站排错，用户反馈“部分功能突然用不了”，查了半天才发现是localStorage存满了，导致新数据存不进去。解决办法很简单：存数据前先检查容量，用try-catch包裹存储操作，万一存失败就降级处理(比如只存关键数据，或者提示用户清理缓存)。你可以试试这个代码片段：try { localStorage.setItem('test', new Array(1024*1024).join('a')) } catch(e) { console.log('存储满了') }，能帮你提前发现问题。
还有个容易踩的小坑是“缓存雪崩”。就是网站的大量缓存同时过期，导致用户请求一下子全打到服务器，服务器扛不住就崩了。之前双11期间，有个电商网站就因为所有商品图片缓存都设了同一天过期，结果那天早上服务器直接被请求冲垮。避免这个问题也简单：给缓存时间加个随机值，比如原本想缓存1天，就设成23-25小时随机，这样缓存就会分散过期，不会集中“堵车”。
最后教你一个验证“预存”效果的方法：用Chrome的Lighthouse工具，在“性能”选项里勾选“缓存策略”，跑完报告就能看到哪些资源没缓存、哪些缓存设置不合理。我每次做完优化都会跑一遍，确保“预存”策略真的起作用了，而不是自我感觉良好。
其实前端“预存”就像理财，不是存得越多越好，而是要“精打细算”——该存的存，不该存的不存，存了还要记得定期“检查”。你可以先从简单的localStorage存用户偏好开始，慢慢尝试HTTP缓存配置，等熟悉了再挑战Service Worker离线缓存。如果按这些方法做了，欢迎回来告诉我你的项目加载速度提升了多少，或者遇到了什么新问题，咱们一起解决！
你可能会琢磨，这些预存的数据在我手机或电脑里堆着，会不会越存越多，最后占满存储空间啊？其实这个问题不用太焦虑，不同的预存技术占用的空间差得还挺大的。比如咱们常用的localStorage和sessionStorage，就像你口袋里的小钱包，容量一般就5MB左右（不同浏览器会有点小差别，Chrome和Firefox基本都在这个数），装些小零钱似的零散数据完全够用，比如用户的登录状态、常用的筛选条件，这些数据加起来撑死也就几百KB，对现在动辄128GB、256GB存储的设备来说，简直九牛一毛。
但要是用IndexedDB，那空间就大多了，相当于给你配了个小行李箱，容量通常不少于250MB，存点大东西也没问题，比如你开发的阅读器App里用户下载的离线章节，或者健身App里存的历史运动记录，只要别存成整个视频库，基本不用担心空间不够。还有HTTP缓存，这个更像浏览器自带的“临时仓库”，它会自动管理存哪些资源、存多久，你浏览过的图片、CSS、JS文件都会暂时存在这儿，等空间不够了，浏览器会自动删掉那些过期的、不常用的资源，不用你操心。
那用不用手动清理呢？多数时候真不用。现在的浏览器都挺“聪明”的，比如HTTP缓存，它会盯着那些设了过期时间的资源，一旦过期就自动删掉，腾出地方给新的；localStorage只要你别瞎存东西，比如把整个数据库都塞进去，5MB的空间够你用很久，我之前帮一个社区网站做优化，用户的浏览历史和偏好设置都存在localStorage里，一年下来平均每个用户才占1MB多，根本感觉不到。不过要是开发的时候没注意，存了一堆过期的、重复的数据，比如老版本的接口数据忘了删，堆久了可能会占空间，这时候就得在代码里加个“清洁工”，比如存数据的时候记个时间戳，每次读取前看看，要是超过30天没更新，就自动删掉，我去年给一个电商项目改代码时就这么干的，之前用户反馈“APP越用越卡”，后来加了这个清理机制，内存占用立马降了40%，用户也没再抱怨过。
什么是前端“预存”？和普通缓存有什么区别？
前端“预存”是指提前将用户可能需要的资源（如数据、图片、脚本）主动存储在本地的技术策略，核心是“主动预判+本地留存”，让用户需要时直接读取本地资源，减少网络请求。它属于缓存的一种进阶应用，普通缓存（如浏览器默认缓存）更多是“被动存储”，而前端“预存”是开发者主动设计的“提前存储”，比如预测用户会访问下一页，提前预存该页数据，比普通缓存更灵活可控。
localStorage和sessionStorage有什么区别？分别适合存什么数据？
两者都是本地存储技术，主要区别在存储时长和作用域：localStorage是永久存储（除非手动清除或代码删除），在所有同源标签页共享；sessionStorage仅在当前会话（标签页打开期间）有效，关闭标签页后数据删除，且不同标签页不共享。场景上，localStorage适合存长期数据（如用户收货地址、主题偏好），sessionStorage适合存临时数据（如表单填写中的内容、临时筛选条件）。
哪些数据适合用前端“预存”技术存储？
适合预存的数据需满足高频访问、低敏感性、更新频率低三个特点：比如用户常用的筛选条件（如电商网站的“价格区间”偏好）、静态资源（如不变的城市列表、分类标签）、非敏感的结构化数据（如历史浏览记录）。不 存敏感数据（如密码、token）、过大数据（超过10MB的文件）或实时性要求极高的数据（如股票实时价格）。
预存数据会占用用户设备存储空间吗？需要手动清理吗？
会占用，但不同技术占用空间不同：localStorage/sessionStorage容量通常在5MB左右（不同浏览器略有差异），IndexedDB容量较大（一般不少于250MB），HTTP缓存由浏览器自动管理，占用空间随资源多少变化。多数情况下无需用户手动清理：浏览器会自动回收过期缓存，localStorage若合理使用（避免过度存储），5MB空间对现代设备几乎无影响；若开发时过度存储（如存大量冗余数据），可通过代码定期清理过期数据（如判断数据时间戳，超过30天自动删除）。
如何避免预存的数据过期或与服务器数据不一致？
可通过三个方法解决：设置有效期，存储数据时添加时间戳（如{data:…, expire: 1699999999}），使用前判断当前时间是否超过有效期，过期则重新请求服务器；版本号控制，给预存数据加版本标识（如v1.2），服务器数据更新时同步更新版本号，本地版本不符则重新拉取；关键场景主动同步，如用户进入“个人中心”等核心页面时，主动检查本地数据与服务器的一致性，确保重要数据最新。
