React中useMemo未获取数组对象最新状态的原因与解法

先给出核心结论：当 useMemo 依赖的数组对象更新后未触发重新计算时，问题根源通常不在 useMemo 本身，而是异步操作中滥用 forEach 导致状态更新时序紊乱。本文将深入剖析这一陷阱，并提供一个基于 Promise.all 的可靠批量处理方案。

在 React 函数组件中，useMemo 的执行机制极为严格：它仅识别依赖数组（deps）的引用变化。当 asyncProcesses 是一个由 useState 管理的数组时，useMemo 只有在该数组变量发生新引用赋值（例如 [...oldArray] 或 array.map(...) 返回新数组）且该新数组被 setAsyncProcesses 同步设置之后，才会重新执行。那么问题究竟出在哪里？答案很直接：在异步操作尚未全部完成之前，就调用了 setAsyncProcesses，导致状态更新进入“竞态”地带。

让我们审视原始代码中的典型错误写法：

asyncProcesses.forEach(async (process, i) => {
  const newProcess = await checkUploadCsvProcess(/* ... */);
  newAsyncProcesses.splice(i, 1, newProcess); // ✅ 修改副本
});
setAsyncProcesses(newAsyncProcesses); // ❌ 过早设置状态！此时 newProcess 尚未全部 resolve

关键点在于：Array.prototype.forEach 是同步方法，即使回调函数被标记为 async，它也不会等待所有 Promise 完成后再执行下一行代码。它会立即启动所有异步任务，然后直接跳到 setAsyncProcesses 这一行。此时，newAsyncProcesses 中的大部分 newProcess 仍处于 pending 状态，因此最终通过状态设置得到的数组是一个部分未完成、字段仍为旧值（如 'uploading'） 的中间态。useMemo 自然获取到这个“过期”版本，无法反映最终的 'success' 状态。

✅ 正确的做法非常清晰：先并发发起所有请求，再统一等待它们全部完成，最后一次性更新状态。推荐使用 Promise.all 配合 map 来实现：

const updateProcesses = async () => {
  try {
    // 并发执行所有检查，返回 Promise 数组
    const updatedProcesses = await Promise.all(
      asyncProcesses.map(async (process, i) => {
        return checkUploadCsvProcess(
          process as AsyncProcessCsvUpload,
          {
            actionName: dictionary.review,
            actionOnClick: () => {
              na vigate(routes.linkedAccounting);
              setIsOpenInDialog(AsyncProcessType.CsvUpload, true);
            },
          }
        );
      })
    );
    // 过滤掉 undefined（例如 catch 中返回的情况），确保类型安全
    const validProcesses = updatedProcesses.filter(Boolean) as AsyncProcess[];
    // 一次性设置最新状态，触发 useMemo 重新计算
    setAsyncProcesses(validProcesses);
  } catch (error) {
    console.error('Failed to update async processes:', error);
  }
};

// 调用此函数替代原有的 forEach 逻辑
updateProcesses();

⚠️ 还有几个值得注意的细节：

• Promise.all 有一个特点：短路失败。只要其中一个 Promise reject，整个组合就会立即 reject。如果您需要容错，可以改用 Promise.allSettled，然后手动过滤出 fulfilled 的结果。
• checkUploadCsvProcess 内部直接修改了传入的 process 对象（例如 process.snackbarType = 'success'），这属于副作用式突变（mutation）。虽然当前场景能工作，但更推荐的做法是返回一个全新对象，保证不可变性（Immutability），例如：

  return {
    ...process,
    snackbarType: 'success',
    isActive: false,
    // ...其他覆盖字段
  };

• useMemo 的依赖项 [asyncProcesses, displayAsSnackbarList, dictionary, removeAsyncProcess] 本身没有问题，无需改动。但务必确保 dictionary 和 removeAsyncProcess 是稳定引用（如通过 useMemo 或 useCallback 创建），否则可能触发不必要的重计算。

总结一下：useMemo 不刷新，并非 Hook 本身失效，而是状态更新逻辑中埋下了一个“竞态条件”的坑。修复思路归结为——将异步操作从“火球式并发 + 提前提交”改为“并发发起 + 聚合等待 + 原子提交”。这个模式不仅解决了 useMemo 的陈旧数据问题，更重要的是大幅提升了状态的一致性和可预测性。在 React 中处理异步状态管理时，这绝对是最值得倡导的最佳实践之一。