React useOptimistic 怎么在请求失败时回滚列表

React useOptimistic 的回滚不是再写一个“撤销删除”的数组，而是保留一份没有被本地请求直接改写的真实列表。删除动作开始时，reducer 只在乐观视图里标记项目；如果 Action 抛错，React 会结束临时状态并重新渲染传入的真实列表，项目自然恢复。请求成功后，再由父组件刷新或更新真实列表，乐观状态与服务端结果收敛。

关键原则：不要先从 items 里删除元素再指望 useOptimistic 找回来；让真实列表保持原样，把“正在删除”放进乐观状态，失败就会自动回到基线。

保留真实列表作为 useOptimistic 的基线

useOptimistic(value, reducer) 的第一个参数是没有待处理 Action 时要显示的值。它不是一份独立的持久状态。只要请求还在进行，组件看到的是 reducer 计算出的临时列表；Action 成功或失败后，React 会重新以 value 为基础渲染。

因此，列表数据最好由父组件或查询缓存持有。例如父组件传入的 items 是最近一次服务端确认结果，子组件只负责把它包装成乐观视图。请求失败时因为 items 没有被提前删掉，回滚不需要保存旧快照。

用 reducer 标记待删除项

删除列表项时，直接把它过滤掉会让用户看不到失败后的恢复过程，也容易在多个请求并发时丢掉基线。更稳妥的做法是保留项目，增加一个只属于乐观视图的 deleting 标记：

import { useState, useOptimistic, startTransition } from 'react';

export default function ItemList({ items, deleteItem }) {
  const [error, setError] = useState('');
  const [optimisticItems, markDeleting] = useOptimistic(
    items,
    (currentItems, id) => currentItems.map(item =>
      item.id === id ? { ...item, deleting: true } : item
    )
  );

  function handleDelete(id) {
    setError('');
    startTransition(async () => {
      // 只修改临时视图，不提前改写服务端确认的 items。
      markDeleting(id);
      try {
        // 这里的 Action 应在成功后让父组件刷新真实列表。
        await deleteItem(id);
      } catch (cause) {
        // 失败时不手写反向操作，useOptimistic 会回到 items。
        setError(cause instanceof Error ? cause.message : '删除失败');
      }
    });
  }

  return (
    
      {optimisticItems.map(item => (
        

          {item.name}
           handleDelete(item.id)}>
            {item.deleting ? '删除中…' : '删除'}
          
        
      ))}
      {error && 
{error}，项目已恢复，请重试。
}
    >
  );
}

这里的 deleting 只改变透明度、按钮文字或禁用状态，读者仍能看到项目。若产品确实要求立即隐藏，也可以在渲染时过滤 deleting 项，但仍不要改动 items 本身；失败后基线重新出现，就完成了回滚。

在 Action 中捕获失败并同步成功结果

markDeleting 必须在 startTransition 的 Action 中调用，否则 React 会提示乐观状态更新不在 Transition 或 Action 内。失败分支只负责展示错误，因为官方语义是 Action 抛错后回到当前的 value。成功分支则不能停在“删除中”：deleteItem 需要让父组件重新获取列表、调用缓存失效，或用服务端返回的新列表更新 state。

这也是很多“回滚不生效”问题的根源：如果调用前就执行了 setItems(prev => prev.filter(...))，那么 useOptimistic 接收到的 value 已经少了一项，失败时只能恢复到错误的新基线。乐观层与持久层要分开。

处理连续操作和竞态边界

列表项的 id 要稳定且唯一，reducer 不应依赖数组下标。多个删除动作同时进行时，reducer 会以当前基线重新计算临时视图，比在事件处理器里闭包捕获旧数组更可靠。若服务端允许并发删除，成功后的刷新应以服务端返回的最终列表为准；若接口存在版本号或权限冲突，应把冲突当作失败，让项目回到基线，而不是继续隐藏。

如果删除成功但界面仍显示项目，问题通常不在回滚，而在成功后没有更新 items。如果失败后项目没有恢复，先检查是否提前调用了真实 state setter，以及异常是否真的从 Action 中被捕获。

常见问题

请求失败时必须手动调用 setItems 恢复吗？不必。只要真实的 items 没有被提前修改，Action 失败后临时乐观状态结束，列表会回到原基线。

为什么按钮点击后 React 提示不在 Action 中？检查 setter 是否位于 startTransition(async () => {}) 或框架提供的 Action prop 内；不要在渲染阶段或普通异步回调里直接调用。

删除成功后还需要保留 deleting 标记吗？不需要。父组件拿到新的服务端列表后，项目被移除；若项目仍存在，新的基线也会覆盖临时标记。

排查时按这五项确认：真实列表没有提前过滤；乐观 setter 在 Action 内；reducer 使用稳定 id；失败只设置错误提示；成功路径会更新 canonical state。满足这组边界，React useOptimistic 的列表回滚就会由状态模型自然完成。