localStorage是同步还是异步的？为什么

2024-06-11

2384 字约 8 分钟

...

点赞 + 收藏 === 学会🤣🤣🤣

首先明确一点，localStorage是同步的

localStorage 是 Web Storage API 的一部分，它提供了一种存储键值对的机制。localStorage 的数据是持久存储在用户的硬盘上的，而不是内存。这意味着即使用户关闭浏览器或电脑，localStorage 中的数据也不会丢失，除非主动清除浏览器缓存或者使用代码删除。

当你通过 JavaScript 访问 localStorage 时，浏览器会从硬盘中读取数据或向硬盘写入数据。然而，在读写操作期间，数据可能会被暂时存放在内存中，以提高处理速度。但主要的特点是它的持久性，以及它不依赖于会话的持续性。

是的，硬盘确实是一个 IO 设备，而大部分与硬盘相关的操作系统级IO操作确实是异步进行的，以避免阻塞进程。不过，在 Web 浏览器环境中，localStorage 的API是设计为同步的，即使底层的硬盘读写操作有着IO的特性。

js代码在访问 localStorage 时，浏览器提供的API接口通常会处于js执行线程上下文中直接调用。这意味着尽管硬盘是IO设备，当一个js执行流程访问 localStorage 时，它将同步地等待数据读取或写入完成，该过程中js执行线程会阻塞。

这种同步API设计意味着开发者在操作 localStorage 时不需要考虑回调函数或者Promise等异步处理模式，可以按照同步代码的方式来编写。不过，这也意味着如果涉及较多数据的读写操作时，可能对性能产生负面影响，特别是在主线程上，因为它会阻塞UI的更新和其他js的执行。

localStorage 实现同步存储的方式就是阻塞 JavaScript 的执行，直到数据的读取或者写入操作完成。这种同步操作的实现可以简单概述如下：

js线程调用: 当 JavaScript 代码执行一个 localStorage 的操作，比如 localStorage.getItem('key') 或 localStorage.setItem('key', 'value')，这个调用发生在 js 的单个线程上。
浏览器引擎处理: 浏览器的 js 引擎接收到调用请求后，会向浏览器的存储子系统发出同步IO请求。此时 js 引擎等待IO操作的完成。
文件系统的同步IO: 浏览器存储子系统对硬盘执行实际的存储或检索操作。尽管操作系统层面可能对文件访问进行缓存或优化，但从浏览器的角度看，它会进行一个同步的文件系统操作，直到这个操作返回结果。
操作完成返回: 一旦IO操作完成，数据要么被写入硬盘，要么被从硬盘读取出来，浏览器存储子系统会将结果返回给 js 引擎。
JavaScript线程继续执行: js 引擎在接收到操作完成的信号后，才会继续执行下一条 js 代码。

在同步的 localStorage 操作期间，由于 js 的单线程性质，整个线程会阻塞，即不会执行其他任何js代码，也不会进行任何渲染操作，直到 localStorage 调用返回。

资源公平分享：同一用户可能会访问大量不同的网站，如果没有限制，随着时间的积累，每个网站可能会消耗大量的本地存储资源。这样会导致本地存储空间被少数几个站点占用，影响到用户访问其他网页的体验。限制大小可以确保所有网站都有公平的存储机会。
防止滥用：如果没有存储限制，网站可能会滥用 localStorage，存储大量数据在用户的设备上，这可能导致设备存储空间迅速耗尽，也可能侵犯用户的隐私。
性能限制：如之前提到的，localStorage 的操作是阻塞的。如果网站能够存储大量数据，就会加剧读写操作对页面性能的影响。
存储效率：localStorage 存储的是字符串形式的数据，不是为存储大量或结构化数据设计的。当尝试存储过多数据时，效率会降低。
历史和兼容性：5MB 的限制很早就已经被大多数浏览器实现，并被作为一个非正式的标准被采纳。尽管现在有些浏览器支持更大的 localStorage，但出于跨浏览器兼容性的考虑，开发者通常会假设这个限制。
浏览器政策：浏览器厂商可能会依据自己的政策来设定限制，可能是出于提供用户更一致体验的角度，或者是出于管理用户数据的方便。

虽然它们提供了更大的存储空间和更丰富的功能，但确实潜在地也可能被滥用。但是与相比 localStorage 增加了一些特性用来降低被滥用的风险：

异步操作：IndexedDB 是一个异步API，即使它被用来处理更大量的数据，也不会像 localStorage 那样阻塞主线程，从而避免了对页面响应性的直接影响。
用户提示和权限：对于某些浏览器，当网站尝试存储大量数据时，浏览器可能会弹出提示，要求用户授权。这意味着用户有机会拒绝超出合理范围的存储请求。
存储配额和限制：尽管 IndexedDB 提供的存储容量比 localStorage 大得多，但它也不是无限的。浏览器会为 IndexedDB 设定一定的存储配额，这个配额可能基于可用磁盘空间的一个百分比或者是一个事先设定的限额。配额超出时，浏览器会拒绝更多的存储请求。
更清晰的存储管理：IndexedDB 的数据库形式允许有组织的存储和更容易的数据管理。用户或开发者可以更容易地查看和清理占用的数据。
逐渐增加的存储：某些浏览器实现 IndexedDB 存储时，可能会在数据库大小增长到一定阈值时，提示用户是否允许继续存储，而不是一开始就分配一个很大的空间。

其实也不用测，平时写的时候你也没用异步的方式写localStorage吧，我们这里简单写个例子

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>

<body>
    <script>
        const testLocalStorage = () => {
            console.log("==========> 设置localStorage之前");
            localStorage.setItem('testLocalStorage', '我是同步的');
            console.log("==========> 获取localStorage之前");
            console.log('=========获取localStorage', localStorage.getItem('testLocalStorage'))
            console.log("==========> 获取localStorage之后");
        }

        testLocalStorage()
    </script>
</body>

</html>

工程化

本系列是一个从0到1的实现过程，如果您有耐心跟着实现，您可以实现一个完整的react18 + ts5 + webpack5 + 代码质量&代码风格检测&自动修复 + storybook8 + rollup + git action实现的一个完整的组件库模板项目。如果您不打算自己配置，也可以直接clone组件库仓库切换到rollup_comp分支即是完整的项目，当前实现已经足够个人使用，后续我们会新增webpack5优化、按需加载组件、实现一些常见的组件封装：包括但不限于拖拽排序、瀑布流、穿梭框、弹窗等