几种前端数据存储方式（记录）

1. cookie

生成cookie是存在客户端，在cookie当用户第一次访问网页时，服务器会给客户端返回一个cookie，在cookie中保存着服务器端session文件的位置信息，用户第一次访问服务器，服务器就会为它创建一个session文件，并将session的标识保存在cookie中发给它。在这之后，通过为每个请求添加 Cookie HTTP 头将信息发送回服务器。
cookie访问和设置在 JavaScript 中可以通过设置字段和进行访问。
cookie优点：Cookie的大小为4kb。cookie主要应用在保存用户身份信息。

Cookie的生成：
服务器端生成：
当用户访问一个网站时，服务器可以设置Cookie并通过Set-Cookie响应头发送给用户的浏览器。
例如，服务器可能会在用户登录后创建一个包含用户会话标识的Cookie。
客户端生成（通常不推荐）：
在某些情况下，客户端（浏览器）可能会根据用户的偏好设置自己的Cookie，但这通常不是标准做法，因为Cookie主要用于服务器与客户端之间的通信。
Cookie的发送：
自动发送：
一旦浏览器接收到Set-Cookie响应头，它会自动将Cookie存储起来，并在随后对同一服务器的请求中自动包含这些Cookie。这是通过在请求头中添加Cookie实现的。
手动发送：
在某些情况下，开发者可能需要在客户端代码中手动发送Cookie。例如，在使用JavaScript的XMLHttpRequest或fetch API时，可以手动设置请求头来包含Cookie。

安全性：Cookie 可以包含敏感信息，因此应该使用Secure和HttpOnly标记来增强安全性。
路径和域：Cookie 可以设置特定的路径和域，这意味着它们只会在特定的URL路径和/或域中被发送。
过期和有效期：Cookie 可以设置过期时间，过期后会自动从客户端删除。

fetch('/api/data', {
  credentials: 'include' // 允许发送Cookie
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

2. localStorage

localStorage介绍：和cookie很类似，但是localStorage的大小有5M；不需要被发送到服务端。还有一个区别localStorage存储的数据是永久性的，其作用域限定在文档源级别（只要URL的协议、端口、主机名三者中有一个不同，就属于不同的文档源）。除此之外，localStorage也受浏览器供应商限制，如果使用chrome访问一个网站，下次用firefox再次访问是获取不到上次存储的数据的。

localStorage特点：页面数据同步
好处localStorage 只能做为提升用户体验的手段，而不能成为客户端逻辑的可靠的、唯一的依赖。方便网页的加载，避免取回数据前页面一片空白，如果不需要最新数据也可以减少向服务端请求的次数，从而减少用户等待从服务器获取数据的时间；网络状态不佳时仍可以显示离线数据。
访问限制只有当前设定localstorage的域下才能访问；单标签页：两个tab（相同域）之间不能互通；刷新或新开 tab 是可以访问到的，关闭浏览器重新打开原先tab也可访问。
localStorage应用：存储一些需要刷新保存并且需要在页面关闭后仍然留下的信息。可以用于保存购物车中的内容；在之前项目中，用于保存上一次的用户浏览标签，并跳转到相应的路径下。
localstorage注意事项：因为性能问题，不能过于依赖。value 尽量使用 string。如果需要多次写入localstorage，尽量一次性写入。localstorage是同步执行，可能会阻塞UI。

3. sessionStorage

存储位置：

sessionStorage数据存储在用户的浏览器中，而且是与特定的浏览器标签（或窗口）关联的。不同的浏览器标签（即使是同一个页面）之间不会共享sessionStorage 数据。
存储限制：

每个域名（origin）都有自己的 sessionStorage 空间，不同域名之间不会共享数据。存储容量通常比 cookies
大，但具体大小可能因浏览器而异，一般认为是 5MB 左右。
生命周期：
sessionStorage 的数据在页面会话期间有效，会话结束时数据被清除。会话是指从打开浏览器窗口到关闭浏览器窗口的这段时间。
访问方式：
可以通过 JavaScript 访问 sessionStorage，使用对象。
使用场景：
适用于需要在浏览器端临时存储数据，但又不希望数据持久保留的场景，比如表单数据的暂存、用户在当前会话中的偏好设置等。
API 方法：
setItem(key, value)：将数据存储到 sessionStorage。 getItem(key)：根据键名获取
sessionStorage 中的数据。 removeItem(key)：从 sessionStorage 中移除指定键名的数据。
clear()：清除 sessionStorage 中的所有数据。 key(index)：获取存储中指定索引的键名。
length：返回存储中键值对的数量。

4. cookie和web storage的区别

Cookie的作用是与服务器进行交互，作为HTTP规范的一部分而存在，而Web Storage仅仅是为了在本地“存储”数据而生。

5. IndexDB

websql 像关系型数据库，使用 sql 语句进行操作。 indexdb 像 nosql，直接使用 js 方法操作数据。

访问：indexdb与 web storage 一致，均是在创建数据库的域名下才能访问。且不能指定访问域名。
存储时间：存储时间永久，除非用户清除数据，可以用作长效的存储。
大小限制：理论上讲，这种存储的方式是没有大小限制的。然而IndexDB的数据库超过50M的时候浏览器会弹出确认。基本上也相当于没有限制了。
性能测试：indexeddb查询少量数据花费差不多20ms左右。大量数据的情况下，相对耗时会变长一些，但是也就在30MS左右，也是相当给力了，10W+数据能够保持相对快速的响应时间，且大部分操作都是异步的，不会对用户体验产生负面影响。

IndexedDB 具有以下特点。

key/value的存储方式：IndexedDB和localStorage的存储方式很类似，都是通过一个key对应一个value，而且key是唯一的方式进行存储的，但是indexedDB和localStorage有很不一样的一点，就是可以直接存储对象数组等，不需要想localStorage那样必须转为字符串。
异步调用：IndexedDB是使用异步调用的，当我们存储一个较大的数据时，不会因为写入数据慢而导致页面阻塞。
支持事务：IndexedDB支持事务，如果有用过mysql和mongoDB的人就很清楚了，能确保我们多个操作只要其中一步出现问题，可以整体回滚。
同源限制：IndexedDB和localStorage一样，都是有同源策略的问题，不能跨协议、端口、域名使用。
储存空间：IndexedDB我认为最最最大的优势在于存储空间相比localStorage要大得多，一般来说不少于250MB。
支持二进制：IndexedDB不但可以存储对象，字符串等，还可以存储二进制数据。

什么场景下使用:

在PC的Chorme中是可以存到localStorage的，但是在IOS中，却报出空间不足，无法放入localStorage中，所以这个时候就是使用indexedDB了！因为indexedDB的空间大得我可以完全不去考虑数据大小，而且还能直接以对象的形式存入，无需转为JSON字符串。大大减少了转换的运算。但是因为使用indexedDB和使用localStorage是完全不一样的，基本上都是异步操作而且还要考虑一些低版本的手机可能不支持的情况，所以要封装中间件，同样的调用，根据设备对indexedDB的兼容情况，自动决定使用indexedDB还是localStorage。最终完成需求，并且优化前后达到超过70%的优化率，页面的渲染基本秒开。
大部分主流程的浏览器其实都已经兼容了indexedDB。

END.

秒客网