如何用JavaScript实现一个支持持久化的状态管理库？-js教程-PHP中文网

答案：实现JavaScript持久化状态管理库需结合响应式状态容器与存储机制，通过createPersistentStore创建支持自动保存、恢复状态的实例，并利用localStorage/sessionStorage/IndexedDB选择合适存储方案，同时处理序列化、反序列化问题，优化性能与多标签同步。

如何用javascript实现一个支持持久化的状态管理库？

在JavaScript中实现一个支持持久化的状态管理库，核心思路其实并不复杂：你需要一个响应式的状态容器，并将其与一个浏览器端的存储机制（比如

localStorage

登录后复制

）结合起来。当状态发生变化时，自动将状态的一部分或全部保存到存储中；应用启动时，则从存储中恢复状态。这就像给你的应用状态安上了一个“记忆芯片”，让它在页面刷新后依然能想起之前的一切。

解决方案

要实现这样一个库，我们可以从一个基础的响应式状态模型开始，然后逐步加入持久化能力。

首先，我们构建一个简单的状态管理工厂函数。它能创建状态、提供获取和设置状态的方法，并支持订阅状态变化。

function createPersistentStore(initialState, storageKey, options = {}) {
    const {
        storage = localStorage, // 默认使用 localStorage
        serializer = JSON.stringify,
        deserializer = JSON.parse,
        // 可以添加一个白名单/黑名单来控制哪些状态需要持久化
        persistKeys = null // 默认持久化所有状态，如果提供数组则只持久化指定key
    } = options;

    let state = initialState;
    const subscribers = new Set();

    // 尝试从存储中加载状态
    try {
        const storedStateString = storage.getItem(storageKey);
        if (storedStateString) {
            const parsedStoredState = deserializer(storedStateString);
            // 合并存储的状态与初始状态，确保新的初始状态字段也能被保留
            state = { ...initialState, ...parsedStoredState };
        }
    } catch (error) {
        console.warn(`Failed to load state from ${storageKey}:`, error);
        // 遇到加载错误时，我们倾向于使用初始状态，避免应用崩溃
    }

    // 持久化状态到存储
    const persistState = () => {
        try {
            let stateToPersist = state;
            if (persistKeys && Array.isArray(persistKeys)) {
                stateToPersist = persistKeys.reduce((acc, key) => {
                    if (Object.prototype.hasOwnProperty.call(state, key)) {
                        acc[key] = state[key];
                    }
                    return acc;
                }, {});
            }
            storage.getItem(storageKey); // 尝试读取，确保storage可用
            storage.setItem(storageKey, serializer(stateToPersist));
        } catch (error) {
            console.error(`Failed to persist state to ${storageKey}:`, error);
            // 存储失败通常是由于存储空间不足或序列化错误
        }
    };

    // 首次加载后就进行一次持久化，确保初始状态也被保存
    // 除非初始状态完全来自存储，否则这步很重要
    persistState();

    return {
        getState() {
            return state;
        },
        setState(updater) {
            const oldState = state;
            const newState = typeof updater === 'function' ? updater(oldState) : updater;
            // 浅比较，避免不必要的更新和持久化
            if (JSON.stringify(oldState) === JSON.stringify(newState)) {
                return;
            }
            state = newState;
            persistState(); // 状态改变时自动持久化
            subscribers.forEach(callback => callback(state, oldState));
        },
        subscribe(callback) {
            subscribers.add(callback);
            return () => subscribers.delete(callback); // 返回一个取消订阅的函数
        }
    };
}

// 示例用法：
// const myStore = createPersistentStore({ count: 0, user: null }, 'myAppStore');
// myStore.setState(s => ({ ...s, count: s.count + 1 }));
// console.log(myStore.getState()); // { count: 1, user: null }
// myStore.subscribe(newState => console.log('State updated:', newState));

登录后复制

这个基础实现提供了一个相对完整的持久化状态管理框架。它处理了状态的初始化、更新、订阅，并集成了错误处理和可选的持久化键控制。我感觉，在实际项目中，我们还需要考虑更细致的优化，比如持久化操作的节流（throttling）或防抖（debouncing），以避免频繁写入存储造成的性能问题。

立即学习“Java免费学习笔记（深入）”；

选择合适的存储机制：localStorage、sessionStorage 还是 IndexedDB？

在前端持久化状态时，我们通常会在

localStorage

登录后复制

、

sessionStorage

登录后复制

和

IndexedDB

登录后复制

之间做选择，每种都有其适用场景和优缺点。

localStorage

登录后复制

：这是最常用的一种，我个人觉得它就像一个轻量级的抽屉，适合存储少量、非敏感且需要跨会话（即关闭浏览器再打开也能保留）的数据。它的API非常简单，直接通过键值对操作字符串，使用起来几乎没有心智负担。缺点也很明显：它同步阻塞主线程，存储容量有限（通常5-10MB），并且只能存储字符串，这意味着你需要手动进行序列化和反序列化。对于我们这个库来说，如果状态对象不大，

localStorage

登录后复制

是首选，因为它最方便。

sessionStorage

登录后复制

：它和

localStorage

登录后复制

很像，API也一样。但关键区别在于其生命周期：数据只在当前会话（浏览器标签页或窗口）有效，一旦关闭标签页或浏览器，数据就会丢失。如果你的状态只希望在用户当前浏览期间保持，刷新页面不丢失，但关闭后就清空，那么

sessionStorage

登录后复制

是合适的选择。例如，一个多步表单的临时数据就很适合用它。

IndexedDB

登录后复制

：这是一个功能更强大的客户端数据库，它提供了异步的、事务性的数据存储能力，能够存储大量结构化数据（通常几十MB到几GB，取决于用户设备）。当你需要存储复杂对象、大量数据，或者对数据进行查询、索引时，

IndexedDB

登录后复制

就显得不可替代了。它的API相对复杂，通常需要借助Promise封装或第三方库（如

Dexie.js

登录后复制

）来简化操作。对于大型应用或离线应用，如果状态管理库需要处理复杂且海量的持久化数据，那么将其底层存储切换到

IndexedDB

登录后复制

会是更稳健的选择。

总结一下，如果你的状态管理库只是处理一些用户偏好设置、简单的用户会话信息，

localStorage

登录后复制

无疑是效率最高的。如果需要处理更复杂、更大规模的数据，或者希望避免同步阻塞，那么

IndexedDB

登录后复制

才是正解。

如何优雅地处理状态的序列化与反序列化？

状态的序列化（将JavaScript对象转换为字符串）和反序列化（将字符串转换回JavaScript对象）是持久化过程中一个非常关键的环节。最常见的工具是

JSON.stringify()

登录后复制

和

JSON.parse()

登录后复制

。它们用起来很简单，但也有一些“坑”需要注意。

首先，

JSON.stringify()

登录后复制

默认只能处理基本类型（字符串、数字、布尔值、null）和普通对象、数组。它会忽略

undefined

登录后复制

、函数、

Symbol

登录后复制

类型的值，并且不能正确序列化

Date

登录后复制

对象（会变成ISO字符串，反序列化后是字符串，而不是Date对象）、

RegExp

登录后复制

对象，更别说自定义类的实例了。

BlessAI

Bless AI 提供五个独特的功能：每日问候、庆祝问候、祝福、祷告和名言的文本生成和图片生成。

查看详情

举个例子：

const complexState = {
    name: 'Alice',
    age: 30,
    isActive: true,
    hobbies: ['reading', 'coding'],
    createdAt: new Date(),
    greet: () => console.log('Hello'),
    score: undefined,
    userMap: new Map([['id1', { name: 'Bob' }]])
};

const jsonString = JSON.stringify(complexState);
// jsonString 会丢失 greet、score 和 userMap，createdAt 会变成字符串
// console.log(jsonString);
// {"name":"Alice","age":30,"isActive":true,"hobbies":["reading","coding"],"createdAt":"2023-10-27T...Z"}

登录后复制

为了“优雅”地处理这些问题，我们有几种策略：

自定义

replacer

登录后复制

和
reviver
登录后复制
函数：

JSON.stringify()

登录后复制

和

JSON.parse()

登录后复制

都支持传入可选的函数参数。

```
replacer
```
登录后复制
（用于
```
stringify
```
登录后复制
）：可以用来过滤或转换要序列化的值。例如，你可以将
```
Date
```
登录后复制
对象转换为特定的格式字符串，或者处理
```
Map
```
登录后复制
/
```
Set
```
登录后复制
。
```
reviver
```
登录后复制
（用于
```
parse
```
登录后复制
）：在反序列化时，可以检查每个键值对，并将特定格式的字符串（如之前转换的Date字符串）还原为原始对象。

// 示例：处理 Date 对象
const customSerializer = (key, value) => {
    if (value instanceof Date) {
        return { __type: 'Date', value: value.toISOString() };
    }
    // ... 处理其他类型，如 Map, Set
    return value;
};

const customDeserializer = (key, value) => {
    if (value && typeof value === 'object' && value.__type === 'Date') {
        return new Date(value.value);
    }
    return value;
};

// 使用
// const serialized = JSON.stringify(complexState, customSerializer);
// const deserialized = JSON.parse(serialized, customDeserializer);
// console.log(deserialized.createdAt instanceof Date); // true

登录后复制

这种方式虽然灵活，但需要你手动编写大量逻辑来处理各种非标准类型，尤其是当你的状态结构复杂时，维护成本会很高。

处理循环引用：如果你的状态对象中存在循环引用（A引用B，B又引用A），
```
JSON.stringify()
```
登录后复制
会直接报错。对于这种情况，通常需要手动解除循环引用，或者在
```
replacer
```
登录后复制
中检测并跳过。
使用第三方库：对于更复杂的序列化需求，比如需要保留函数、正则、
```
Map
```
登录后复制
/
```
Set
```
登录后复制
甚至自定义类的实例，手动编写
```
replacer
```
登录后复制
和
```
reviver
```
登录后复制
会变得非常繁琐且容易出错。这时，可以考虑使用一些专门的库，例如
```
superjson
```
登录后复制
。这些库通常提供了更强大的序列化能力，能够处理更多JavaScript数据类型，并自动解决循环引用问题，大大减轻了开发者的负担。它们会通过在JSON中添加元数据的方式来标记和重建复杂类型。

在我看来，对于大多数场景，如果你的状态主要是普通对象和数组，

JSON.stringify

登录后复制

parse

登录后复制

足够了。但一旦涉及到

Date

登录后复制

、

Map

登录后复制

、

Set

登录后复制

或自定义类的实例，我强烈建议要么编写精细的

replacer

登录后复制

reviver

登录后复制

，要么直接引入像

superjson

登录后复制

这样的库，以避免潜在的数据丢失和运行时错误。

在大型应用中，如何优化持久化性能与同步策略？

当你的应用规模变大，状态变得复杂，或者有多个浏览器标签页同时访问时，持久化操作的性能和同步策略就显得尤为重要了。

持久化操作的节流与防抖（Throttling & Debouncing）：频繁地调用
```
storage.setItem()
```
登录后复制
，尤其是在状态频繁更新的场景下，会带来不必要的性能开销。
```
localStorage
```
登录后复制
是同步操作，会阻塞主线程，导致UI卡顿。
- 防抖（Debouncing）：在状态更新后，等待一个短时间（比如100ms），如果在这段时间内没有新的状态更新，才执行持久化。这适用于用户输入等场景，避免每次按键都写入存储。
- 节流（Throttling）：在一段时间内（比如每500ms），最多执行一次持久化。这适用于高频事件，确保在一定时间间隔内至少保存一次最新状态。我通常会选择防抖，因为它能更好地保证在“稳定”状态下进行持久化，减少不必要的写入。
异步存储操作：如果你的持久化数据量很大，或者对性能要求极高，那么应该考虑将底层存储切换到异步API，例如
```
IndexedDB
```
登录后复制
。
```
IndexedDB
```
登录后复制
的所有操作都是异步的，不会阻塞主线程。当然，这也意味着你的状态管理库需要适配异步的读写逻辑，比如在加载状态时返回Promise。

处理多个标签页/窗口的同步：当用户在同一个浏览器中打开了应用的多个标签页时，一个标签页的状态更新并持久化后，其他标签页并不会自动感知到。这时，

window.onstorage

登录后复制

事件就派上用场了。当

localStorage

登录后复制

或

sessionStorage

登录后复制

在不同标签页/窗口被修改时，除了修改当前标签页/窗口，其他所有同源的标签页/窗口都会触发

storage

登录后复制

事件。你可以监听这个事件，并在事件触发时重新从存储中加载状态，从而实现多标签页之间的状态同步。

window.addEventListener('storage', (event) => {
    if (event.key === 'myAppStore' && event.newValue !== null) {
        // 重新从 event.newValue 中解析状态并更新当前 store
        // 注意：event.newValue 是字符串，需要反序列化
        try {
            const newState = JSON.parse(event.newValue);
            // 此时不应该直接调用 setState，因为 setState 会再次触发 persistState，
            // 可能会导致循环触发或不必要的写入。
            // 而是直接更新内部状态，并通知订阅者。
            // myStore.updateInternalState(newState);
        } catch (e) {
            console.error('Failed to parse state from storage event', e);
        }
    }
});

登录后复制

需要注意的是，

storage

登录后复制

事件只在非当前修改页触发。所以，在修改当前页面的状态时，仍然需要正常更新并持久化。

部分持久化（Partial Persistence）：并不是所有的状态都需要持久化。例如，一些UI的临时状态（如模态框的打开/关闭状态、表单的校验信息）在页面刷新后通常不需要保留。只持久化那些真正需要保留的状态切片，可以显著减少存储的数据量，加快序列化和反序列化的速度。这可以通过在
```
createPersistentStore
```
登录后复制
中传入一个
```
persistKeys
```
登录后复制
数组来实现，就像我们之前在解决方案中做的那样。只对指定键进行序列化和反序列化，避免了无用数据的存储和处理。