React useOptimistic 多次提交同时进行时怎样合并状态

React useOptimistic 处理多次并发提交时，应把已确认的基准状态和待确认操作分开，用纯更新函数按稳定标识合并；响应到达后，再用函数式 setState 将单次结果归入最新基准。失败只处理对应操作，不能恢复提交前的整份列表，否则可能覆盖其他已成功的提交。Hook 管理乐观界面，不负责服务器请求的顺序与冲突裁决。

官方地址：https://react.dev/reference/react/useOptimistic

这个特性解决什么：连续点新增，别让旧快照盖住新结果

以连续新增两条待办为例，用户不必等第一条返回就能提交第二条。最容易写错的是在异步函数里保存旧列表，成功后用“旧列表加结果”替换状态。第二个响应先返回、第一条后返回时，较晚的赋值可能丢掉另一条已完成数据。

这里采用一个构造案例拆解实现，没有实际试用或线上故障经历。场景限定为相互独立的新增项，不讨论同一条数据的多次编辑。独立新增可以按标识合并；同一对象冲突则需要额外版本与顺序协议。

支持范围与合并规则：基准更新后，乐观操作仍需可重放

本文面向 React 19 及以上的 useOptimistic 与异步 Action 用法。代码中的 reducer 接收当前状态和操作，必须是纯函数；随机 ID、网络请求和其他副作用都放在用户操作与 Action 中。基准变化时，待处理乐观操作需要能在新的状态上重新计算，不能依赖第一次渲染时捕获的列表。

示例为每次操作分配 clientId。基准中的 items 保存确认项，errors 保存失败项；乐观 reducer 只有在该 ID 尚未确认、也未失败时才添加临时项。这样服务器确认已进入基准后，仍待处理的乐观叠加不会再制造重复行。

最小示例：独立新增项按 clientId 合并

下面是组件代码。调用方需要提供 saveItem(draft)：成功返回持久化项，包含原 clientId 与最终 title；失败应拒绝 Promise。这个接口是本文的应用约定，并非 React 自动提供的服务器能力。

import { useOptimistic, useState, useTransition } from "react";

function optimisticAdd(state, draft) {
  // 已确认或失败的操作，不再叠加临时项；该函数保持纯净。
  if (state.errors[draft.clientId] ||
      state.items.some(item => item.clientId === draft.clientId)) {
    return state;
  }
  return { ...state, items: [...state.items, { ...draft, pending: true }] };
}

export default function ItemList({ saveItem }) {
  const [base, setBase] = useState({ items: [], errors: {} });
  const [view, addOptimistic] = useOptimistic(base, optimisticAdd);
  const [text, setText] = useState("");
  const [isPending, startTransition] = useTransition();

  function submit(event) {
    event.preventDefault();
    const title = text.trim();
    if (!title) return;
    // ID 在用户操作中产生，不能放进 reducer。
    const draft = { clientId: crypto.randomUUID(), title };
    setText("");
    startTransition(async () => {
      addOptimistic(draft);
      try {
        // 应用接口约定：服务端保存该标识并在结果中回传。
        const saved = await saveItem(draft);
        if (saved.clientId !== draft.clientId) {
          throw new Error("响应缺少匹配的 clientId");
        }
        startTransition(() => {
          setBase(current => ({
            ...current,
            items: [
              ...current.items.filter(item => item.clientId !== saved.clientId),
              { ...saved, pending: false },
            ],
          }));
        });
      } catch (error) {
        // 只标记本操作失败，不恢复提交前的整份列表。
        startTransition(() => {
          setBase(current => ({
            ...current,
            errors: { ...current.errors, [draft.clientId]: title + "：提交失败" },
          }));
        });
      }
    });
  }

  return (
    

         setText(event.target.value)} />
        新增
      
      
{isPending ? "仍有提交处理中" : "本轮提交已结束"}
      
{view.items.map(item =>
        
{item.title}{item.pending ? "（待确认）" : ""}
      )}
      {Object.entries(view.errors).map(([id, message]) =>
        
{message}
      )}
    
  );
}

输入框状态在普通事件处理里立即更新，乐观新增放在 startTransition 的 Action 中。await 后更新基准再次包装 startTransition，以明确过渡更新边界。成功归并使用 setBase(current => ...)，因此读取的是待更新的当前基准，而不是请求发出那刻的数组。

为了允许并发，按钮没有因为 isPending 就禁用。isPending 是整体处理状态，不是每个网络请求独立完成标记。每行 pending 则来自乐观项；服务器确认项用相同 clientId 对应到临时项，避免 key 随响应变化导致不必要的重新挂载。

失败处理：撤掉的是一个操作，不是整份页面历史

假设 A 成功、B 失败，基准最终包含 A 和 B 的错误记录。失败不会调用 setBase(oldSnapshot)，所以不会误删 A。reducer 见到 B 的失败标识后不再叠加 B 的临时行。这种逐项失败状态也不依赖“每个请求结束就立即独立移除乐观项”的假设。

多个并发 Transition 可能被一起处理，因此不要把 isPending 的变化当作某个请求的唯一通知。示例直接让成功与失败都更新基准，通过标识决定当前项的显示。所有相关操作结束后，视图回归基准；错误消息仍保留，方便让用户知道哪一次未获确认。

“请求失败”也不总能证明服务器没有保存：网络中断或响应格式不符时，持久化结果可能不确定。因此 clientId 应用于服务端幂等与查询关联；重试时保留原操作标识，并先明确服务端契约，避免每次重试都创建一条新记录。Hook 自身不提供幂等保证。

兼容处理与边界：列表合并不等于覆盖更新排序

本例按成功归并的顺序显示确认项，没有承诺严格按用户点击顺序排列。需要固定显示顺序时，应额外保留提交序号或服务端排序字段，并使用独立排序规则；不能把网络返回顺序当成业务顺序。

若两次提交修改的是同一条记录，例如先改为“进行中”再改为“完成”，仅按 ID 去重还不够。应选择版本检查、串行队列或明确的最后意图规则，并让服务端参与冲突处理。客户端忽略旧响应，并不能阻止服务器先后写入造成覆盖。

大量列表项下，some、filter 和数组复制都有成本。示例优先清楚表达规则；规模较大时可考虑按标识维护索引、限制未完成请求数，并控制错误状态的保留数量。优化数据结构时仍要保证 reducer 与 state updater 的纯净性，不原地修改共享数组。

常见问题

失败时只让 Action 结束就够了吗

简单单次场景可以回归未改变的基准，但并发场景还应明确逐项状态与错误反馈。本文把失败操作记入基准，让合并规则能够立即识别，不恢复整份旧列表。

updateFn 可以生成随机 ID 吗

不应这样做。纯函数重新计算时必须保持相同操作标识，ID 应在用户提交时生成并随请求保存。

useOptimistic 会自动解决请求乱序吗

不会。它帮助显示待确认变化；响应合并、覆盖冲突、幂等和业务排序仍是应用协议的一部分。

参考资料

• React useOptimistic：纯更新函数与乐观状态
• React useTransition：异步 Action 与顺序边界
• React useState：函数式更新队列