React用户缓存：useContext与全局变量选型及非组件内更新方法

非React组件独立TS服务中更新Context缓存值的实现方法 #

首先明确核心限制：useContext属于React Hook，只能在React函数组件、自定义Hook的顶层作用域调用，独立服务文件不属于上述范畴，直接调用必然触发ESLint规则报错。正确的实现思路是采用依赖注入模式，让服务模块完全不直接依赖React API：

• 第一步：在UserService中定义可被外部赋值的更新函数引用，不直接绑定任何React方法
  示例代码：

// UserService.ts
// 提前声明可接收外部更新方法的变量，初始为null
let cacheUpdateFn: ((updater: (prev: Record<number, IUser>) => Record<number, IUser>) => void) | null = null;

// 暴露注入方法，供React侧调用
export const injectCacheUpdateHandler = (handler: typeof cacheUpdateFn) => {
  cacheUpdateFn = handler;
};

// 改造原有fetchUserFromID逻辑
export const fetchUserFromID = async (id: number): Promise<IUser> => {
  try {
    const res = await fetch("users.json");
    const users = await res.json();
    // 拿到用户数据后，调用注入进来的更新函数同步Context状态
    cacheUpdateFn?.((prevCache) => {
      const updatedCache = { ...prevCache };
      Object.keys(users).forEach((userKey) => {
        const currentUser = users[userKey];
        if (!currentUser) {
          console.warn(`Found null user:  ${userKey}`);
          return;
        }
        updatedCache[currentUser.id] = currentUser;
      });
      return updatedCache;
    });
    // 原有返回逻辑保持不变
    const targetUser = updatedCache[id];
    return targetUser;
  } catch (e) {
    console.error(`Failed to fetch user from ID: ${id}`, e);
    throw Error("Unable to fetch the selected user.");
  }
};

• 第二步：在Context对应的Provider组件中，将状态更新方法注入到UserService中
  示例代码：

// 应用根组件的Provider部分
const [userCache, setUserCache] = useState<Record<number, IUser>>({});
// 组件挂载时一次性注入更新方法
useEffect(() => {
  injectCacheUpdateHandler((updater) => setUserCache(updater));
}, []);

return (
  <UserCacheContext.Provider value={{ userCache }}>
    {/* 挂载应用其他子组件 */}
  </UserCacheContext.Provider>
);

这种模式的好处是服务模块完全解耦React逻辑，所有React依赖都由上层组件初始化时传入，从根源上避免Hook调用规则的报错，也方便后续对服务逻辑做独立测试。应用卸载时记得将注入的更新函数重置为null，避免内存泄漏。

低变动频率缓存场景下的方案选择 #

两种方案没有绝对的优先级差，需要结合实际需求判断：

• 如果缓存的读取场景本身不需要触发组件响应式更新：比如只是存一些全局通用的静态数据，所有读取组件都不需要跟着缓存变化自动重渲染，那使用全局普通对象完全够用，实现轻量、没有额外的框架逻辑开销，没必要强制迁移到Context。
• 如果缓存的核心需求是变化时需要自动通知关联组件更新：全局普通变量天生不具备响应式通知能力——哪怕你直接修改全局对象的属性，React也完全感知不到变化，组件不会自动重渲染。如果自己手写一套发布订阅机制来实现通知，工作量和维护成本和直接用Context差不多，还容易出现监听器泄漏、通知时机不一致的问题。
• 低变动频率的缓存场景，恰好是Context的优势区间：Context的常见性能问题是值变动时会触发所有消费组件重渲染，如果缓存变动非常频繁，确实会带来不必要的性能损耗；但如果变动很少，这个性能影响可以完全忽略，换来的是和React生态对齐的状态更新逻辑，不需要自己造通知机制的轮子。
• 如果想兼顾两者的优势，也可以不用强制迁移到Context：在原有的全局缓存基础上，自己加一层简单的发布订阅逻辑，组件挂载时注册对应用户缓存的监听、卸载时移除注册，这种实现的粒度更细，只有真正关心对应缓存变化的组件才会收到通知，性能表现甚至比Context更好。

内容的提问来源于stack exchange，提问作者TheUnreal