手动实现乐观更新

手动实现乐观式更新时，应先使用服务器数据初始化本地组件状态：const [items, setItems] = useState(serverItems)。您要渲染的是这个本地状态，进行乐观式变更的也是这个状态。请勿直接修改从服务器获取的数据——应保留一份由您控制的本地副本。

当用户触发变更操作（点击“添加”“点赞”或“删除”）时，请在调用应用程序接口之前立即更新状态：setItems(prev => [...prev, newItem])。界面会即时反映变化。只有完成这次更新后，才发送实际的网络请求。

执行乐观式更新之前，请保存当前状态：const previousItems = items。这个快照就是回滚目标。如果应用程序接口调用失败，您可以恢复这个值。请将它存储在变量中，而不是状态中，因为您只需要在变更操作等待完成期间使用它。

完成乐观式更新后，异步发起应用程序接口调用，并将其包装在 try/catch 中。成功时，您可以选择重新获取数据以便与服务器状态同步，也可以在服务器会返回相同数据的情况下直接信任乐观式状态。失败时，请使用之前保存的状态进行回滚。

在变更操作的 catch 代码块中执行：setItems(previousItems)。这会将状态恢复到乐观式更新之前的状态。回滚后请显示错误通知。用户能够理解偶尔发生的失败，但无法接受的是界面无提示地处于不一致状态。

回滚后，请显示错误消息：“无法保存更改，请重试。”并提供一个“重试”按钮，用于再次触发相同的变更操作。这样可以让用户掌握主动权。回滚、错误提示和重试结合起来，就能在不阻塞整个界面的情况下妥善处理失败情况。

以乐观方式添加新项目时，服务器还没有为它分配真实 ID。请为这个乐观式项目创建一个临时 ID：const tempId = crypto.randomUUID()。将其用作列表中该项目的键。应用程序接口成功响应后，再将临时 ID 替换为服务器分配的真实 ID。

创建变更操作成功后，服务器会返回真实 ID。请更新状态，替换临时项目：setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item))。这种协调过程可以确保后续操作使用正确的服务器 ID。

如果用户在短时间内连续触发两次变更操作，响应可能会乱序到达。第二次变更操作的响应可能先于第一次到达，而第一次操作的回滚可能会覆盖第二次操作产生的正确状态。这是乐观式界面特有的一种竞态条件。

解决竞态条件的一种方法是使用队列将变更操作串行化。变更进行期间，请禁用触发按钮（将 isSubmitting 状态设为启用）。只有在上一次变更完成后，才允许执行下一次变更。这会牺牲一些响应速度，但能保证状态顺序正确。

对于删除操作：先捕获之前的项目列表，从状态中过滤掉要删除的项目，调用删除接口，并在失败时回滚。删除比创建更简单（不需要协调 ID），但适用的原则相同。您可以考虑在调用接口前短暂延迟删除操作，并显示一个“撤销”选项。

为什么乐观添加的项目需要临时 ID？

手动模式：捕获 previousItems，使用 setItems 设置新状态，调用接口，并在失败时使用 setItems(previousItems) 回滚，同时显示错误。添加项目时，使用 crypto.randomUUID() 作为临时 ID，并在成功后将其与服务器 ID 对应起来。在变更进行期间禁用触发器，以防止竞态条件。回滚 + 提示消息 + 重试是标准的失败交互方式。