先给出核心结论：当 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 中处理异步状态管理时，这绝对是最值得倡导的最佳实践之一。
