多租戶下，探索如何設計Zustand的store？

面临问题：

1. Zustand无法动态根据参数进行初始化。（初始化必须是静态的！）

导致问题：无法一个租户一个localStorage key。

解决办法：只能全部塞进同一个localStorage key

导致问题：不可扩展，随着租户变多，单个key的value会无限变长。

假如一定要用zustand解决以上问题：

1. 架構計劃

// store 中的 structure
state = {
  currentTenant: 'Nike',
  tenants: {
    Nike: {
      cart: [...],
      user: ...
    },
    Pepsi: {
      cart: [...],
      user: ...
    },
  },
  addCartItem: (item) => { /* 操作 tenants[currentTenant].cart */ },
  removeCartItem: (id) => { ... },
  ...
}

初始化的時候我currentTenant是defaultValue = ‘defaultTenant’，tenantMap會根據一個固定的TenantKeyList進行初始化（包含Nike和Pepsi），包含一個初始身份的 ‘defaultTenant’Key。這樣的話我初始化就用defaultTenant，當我client組件用到zustand的時候可以放心使用hook，變量処使用const cart = useStore((s) => s.tenants[s.currentTenant].cart);
。然後在useEffect中，我設置setCurrentTenant = window.location.pathname 裏面提取出來的tenant。於是改變了 currentTenant，對應的cart變量也會改變。就能夠完成：client能夠用hook。useEffect之後根據外部參數，能夠改變zustand顯示。

2. localStorage persist 在多租戶下有瓶頸，擴展為 IndexedDB？

persist(
  (set) => ({
    ...
  }),
  {
    name: 'cart-store',
    storage: createIndexedDBStorage('multi-tenant-app'), // ✅ 替換 storage 層
  }
)

import { get, set, del } from 'idb-keyval';

export function createIndexedDBStorage(prefix: string): StateStorage {
  return {
    getItem: async (name) => {
      return await get(`${prefix}-${name}`);
    },
    setItem: async (name, value) => {
      await set(`${prefix}-${name}`, value);
    },
    removeItem: async (name) => {
      await del(`${prefix}-${name}`);
    },
  };
}

但是始终属于非主流行为

zustand本身设计的轻量就决定了非常适合单租户SPA。

多租户场景天生不是zustand解决的范畴。

那么正确做法是改变工具！选择Redux Toolkit，大型应用。

🌐 技术选型的边界：一次关于 Zustand 与 App Router 的架构瓶颈排查实录

在开发支持多租户的电商平台过程中，我遇到了一个非常棘手的问题：客户端状态管理与多租户架构之间产生了冲突。这次问题的定位与解决经历，让我对“技术选型的边界”有了前所未有的清晰认识，也促使我重新思考架构的适配性。

以下是我在这次排查过程中的完整思路和收获。

🧭 S：背景（Situation）

我正在开发一个支持多租户的 SSR 电商系统，需求如下：

每个租户拥有独立的购物车（即状态持久化 key 隔离）；
系统基于 Next.js App Router 架构；
状态管理使用 Zustand + persist 插件；
状态初始化依赖 tenantName，需在页面渲染前完成。

🎯 T：任务（Task）

在 Layout 中，需要确保：先获取 tenantName，再初始化状态 store，然后再渲染子组件，顺序必须严格控制；
寻找一种方式使 Zustand 能根据 tenantName 动态初始化 store，并实现持久化 key 隔离；
判断 Zustand 是否适合多租户场景，或者是否该更换状态管理工具。

🔍 A：行动（Action）

✅ 1. Zustand 动态初始化的方案探索

我首先尝试使用懒加载的方式：

结果：

子组件中调用 useStore() 时永远拿到的是 undefined；
即使在 Layout 中先执行了 init()，依然无法保证子组件拿到初始化后的状态。

本质原因：

React 的渲染调度机制遵循：

React 渲染会等待“值依赖”的计算完成（同步执行），但不会等待“副作用对共享变量的赋值”。

而 Zustand 的懒加载写法属于“副作用赋值 + 模块变量共享”范式，它脱离了 React 的依赖追踪体系，因此 React 无法保证初始化与消费的时序一致性。

结论：

Zustand 虽然设计上支持多 store，但它的默认用法（静态 hook + 全局 store 实例）并不适合需要“运行时参数参与初始化”的场景。

若要通过 Provider 注入 store，必须把所有 hook 动态包裹后传给组件，使用方式极其复杂，极大破坏开发体验。

判断：Zustand 不适合用于“运行时参数驱动的状态初始化”场景，建议更换工具。

✅ 2. Zustand 能否通过结构变化支持多租户？

我尝试调整 persist key 的策略：

旧方案：localStorage key = cart-${tenantName}；
新方案：localStorage key = cart，value 格式改为 { [tenantName]: cartData }，以共享结构容纳所有租户数据；
如果超出 localStorage 容量，则考虑 IndexedDB 替代。

🧠 判断：

虽然该方案在逻辑上可行，但结构不优雅，实际维护成本高，而且业务复杂度会上升。属于一种 workaround，但不是长远方案。

✅ 3. 架构调整与工具替换

我最终做出决策：

将 Zustand 替换为 Redux Toolkit；
使用 configureStore(tenantName) 同步创建 store；
将 store 作为值传入 <Provider store={store}>，以保证在 React 渲染过程中初始化与消费的稳定顺序。

🧾 R：结果（Result）

成功实现了多租户隔离状态的持久化；
SSR 架构保持稳定，避免了因状态未初始化导致的闪烁、错乱等问题；
整个状态流转路径清晰、稳定、可控。

🧠 这次经历让我深刻认识到：
技术选型本质上是一种架构决策。
很多时候，问题并不出在代码实现，而是工具本身是否适配你当前的模型。

也加深了我对 React 并发渲染模型的理解：

✅ React 渲染流程能等待“作为值传入组件的依赖”，但无法感知“模块级副作用何时完成”。
✅ 如果状态的初始化依赖运行时参数，就必须通过“值传递”方式注入，而非依赖副作用赋值。

🎯 状态管理工具的选择，不能只看“是否轻量”，还要考虑它的设计哲学是否与你当前架构的需求匹配。
Redux 不一定是“更好”的工具，但它更适合“运行时参数注入 + 统一 Provider” 的多租户 SSR 场景。

posted @ 2025-07-07 03:07 PEAR2020 阅读(29) 评论(0) 收藏举报

刷新页面返回顶部

PEAR2020

多租戶下，探索 如何設計Zustand的store？