Ajax不负责持久化，真正实现接口数据本地持久化需结合浏览器存储机制：localStorage适合简单JSON数据、IndexedDB适合大量可查询数据、sessionStorage适合临时会话缓存，并需处理过期与同步问题。
Ajax 本身不负责持久化，它只是发起网络请求、获取数据的手段。真正实现“接口数据本地持久化”的，是在 Ajax 成功拿到响应后，用浏览器提供的存储机制把数据存下来，后续页面重载或再次访问时再读取使用。
用 localStorage 存简单结构化数据
适合保存 JSON 格式的接口返回结果（如用户信息、配置项、列表快照等），操作轻量、代码简洁。
- 请求成功后，把 response 数据转成字符串存进 localStorage：
localStorage.setItem('userInfo', JSON.stringify(data));
- 页面加载时，优先尝试从 localStorage 读取，有则直接渲染，无则触发 Ajax 请求：
const cached = localStorage.getItem('userInfo');
if (cached) {
renderUser(JSON.parse(cached));
} else {
fetch('/api/user').then(r => r.json()).then(data => {
localStorage.setItem('userInfo', JSON.stringify(data));
renderUser(data);
});
}
立即学习“Java免费学习笔记（深入）”；
- 注意：localStorage 只支持字符串，对象必须 JSON.stringify / JSON.parse；单个域名下容量约 5–10MB，超出会报错。
用 IndexedDB 存大量或需查询的数据
当接口返回的是成百上千条记录（如日志、消息列表、离线商品库），且需要按字段筛选、分页、更新某几条时，localStorage 就力不从心了，这时该用 IndexedDB。
- 它支持事务、索引、二进制数据，是浏览器内置的完整数据库；数据不会因刷新丢失，也不受字符串限制。
- 典型流程：打开数据库 → 创建对象仓库（类似表）→ 在事务中 add/put/get/delete 数据。
- 例如缓存搜索结果：
const tx = db.transaction('searchResults', 'readwrite');
const store = tx.objectStore('searchResults');
store.put({ keyword: '前端', items: data, timestamp: Date.now() }, keyword);
- 推荐搭配 Dexie.js 这类封装库，写法更接近 SQL，避免原生 API 的嵌套回调。
配合 sessionStorage 做临时会话缓存
如果数据只需在当前标签页生命周期内有效（比如表单草稿、临时筛选条件），用 sessionStorage 更合适——关掉标签就自动清空，省去手动清理逻辑。
- 写法和 localStorage 几乎一样：
sessionStorage.setItem('searchFilters', JSON.stringify(filters));
- 适用于“用户刚搜完，切到别页再回来还想看到同样结果”这类场景，比 localStorage 更精准控制生命周期。
注意失效与同步问题
本地持久化不是“一存永逸”，得考虑数据过期和服务器一致性：
- 给缓存加时间戳，读取时判断是否超过 5 分钟，超时则重新请求并更新本地存储；
- 关键操作（如提交订单、修改密码）后，主动清除相关缓存，避免下次读到旧数据；
- 如果后端数据可能被其他设备修改，建议加版本号或 ETag，请求时带上，服务端可返回 304 或新数据。
