Zustand Store 状态同步问题分析与解决方案

问题背景#

在使用 Zustand 构建复杂状态管理时，经常会遇到需要组合多个子 store 的场景。本文通过一个实际案例，分析了在组合 store 时遇到的状态同步问题，并提供了相应的解决方案。

问题描述#

原始代码结构#

1
const useDeviceStore = create((set, get) => ({
2
  // 问题：这种方式只获取初始状态，不会响应子store的变化
3
  ...useDeviceIdentityStore.getState(),
4
  ...useNetworkStatusStore.getState(),
5
  ...useOperationStatusStore.getState(),
6
  ...useDeviceInfoStore.getState(),
7

8
  _initialized: false,
9
  init: async () => {
10
    // 初始化逻辑
11
    await useDeviceIdentityStore.getState().init();
12
    set({ _initialized: true });
13
  },
14
}));
15

16
// src/pages/mainTab/index.jsx - 组件使用
17
const MainTab = () => {
18
  const deviceId = useDeviceStore((state) => state.deviceId); // 始终为空
19
  const accessCode = useDeviceStore((state) => state.accessCode); // 始终为空
20
  // ...
21
};

问题现象#

设备初始化成功（控制台显示 deviceId: 'E00E40', accessCode: 'CJRA88'）
但组件中获取到的 deviceId 和 accessCode 始终为空字符串
子 store 状态正常，主 store 状态不同步

问题根源#

状态组合方式错误：使用 ...useDeviceIdentityStore.getState() 只会在 store 创建时获取一次初始状态，不会建立响应式连接。当子 store 状态更新时，主 store 不会自动同步。

解决方案对比#

方案1：订阅机制（推荐）#

优点：

保持原有 API 结构
自动状态同步
类型安全
易于维护

缺点：

代码稍复杂
需要额外的订阅逻辑

1
// src/store/device/index.js - 修复后的主 store
2
const useDeviceStore = create((set, get) => ({
3
  _initialized: false,
4
  init: async () => {
5
    await useDeviceIdentityStore.getState().init();
6
    set({ _initialized: true });
7
  },
8
}));
9

10
// 订阅子store的变化并同步到主store
11
useDeviceIdentityStore.subscribe((state) => {
12
  useDeviceStore.setState({
13
    deviceId: state.deviceId,
14
    accessCode: state.accessCode,
15
  });
16
});
17

18
useNetworkStatusStore.subscribe((state) => {
19
  useDeviceStore.setState({
20
    networkConnectedStatus: state.networkConnectedStatus,
21
  });
22
});

方案2：直接使用子 store#

优点：

实现简单
性能更好（减少一层代理）
状态直接响应

缺点：

破坏原有 API 结构
组件需要知道具体的子 store
可能导致组件耦合度增加

1
// src/pages/mainTab/index.jsx - 直接使用子 store
2
import useDeviceIdentityStore from "@/store/device/deviceIdentity";
3
import useNetworkStatusStore from "@/store/device/networkStatus";
4
import useDeviceInfoStore from "@/store/device/deviceInfo";
5

6
const MainTab = () => {
7
  const deviceId = useDeviceIdentityStore((state) => state.deviceId);
8
  const accessCode = useDeviceIdentityStore((state) => state.accessCode);
9
  const networkConnectedStatus = useNetworkStatusStore(
10
    (state) => state.networkConnectedStatus,
11
  );
12
  const linkStatus = useDeviceInfoStore((state) => state.linkStatus);
13
  // ...
14
};

最终选择#

根据项目实际情况，我们选择了方案2，原因如下：

简单直接：避免了复杂的订阅逻辑
性能优化：减少了不必要的状态代理
代码清晰：组件直接使用需要的子 store，意图明确
维护性好：减少了中间层，降低了复杂度

修复后的代码#

1
import useDeviceIdentityStore from "@/store/device/deviceIdentity";
2
import useNetworkStatusStore from "@/store/device/networkStatus";
3
import useDeviceInfoStore from "@/store/device/deviceInfo";
4

5
const MainTab = () => {
6
  // 直接从对应的子 store 获取状态
7
  const deviceId = useDeviceIdentityStore((state) => state.deviceId);
8
  const accessCode = useDeviceIdentityStore((state) => state.accessCode);
9
  const networkConnectedStatus = useNetworkStatusStore(
10
    (state) => state.networkConnectedStatus,
11
  );
12
  const linkStatus = useDeviceInfoStore((state) => state.linkStatus);
13
  const updateAccessCode = useDeviceIdentityStore(
14
    (state) => state.updateAccessCode,
15
  );
16

17
  // 现在 deviceId 和 accessCode 能正确获取到值
18
  console.log("deviceId:", deviceId); // 'E00E40'
19
  console.log("accessCode:", accessCode); // 'CJRA88'
20

21
  // ... 其他组件逻辑
22
};

经验总结#

避免静态状态组合：不要使用 ...store.getState() 来组合状态
选择合适的状态管理策略：
- 简单场景：直接使用子 store
- 复杂场景：使用订阅机制
保持状态响应性：确保状态变化能够正确传播
考虑性能影响：减少不必要的状态代理和订阅