乐观更新是前端用JS实现的UI先行更新策略，即先修改DOM再发请求，失败后回滚；HTML本身无此机制，仅承载渲染结果。
什么是乐观更新，它和 HTML 本身没关系
HTML 是静态标记语言，不处理状态变更逻辑，也不存在原生的“乐观更新”机制。所谓“HTML 做乐观更新”，实际是指：在基于 HTML 构建的前端界面中（比如用 document.getElementById 直接操作 DOM 的脚本），模拟乐观更新行为——即先更新 UI，再发请求，失败后再回滚。
这种做法常见于按钮点击、列表增删等低延迟交互场景，核心目标是提升感知响应速度。但必须由 JS 主动控制，HTML 只负责承载最终渲染结果。
用原生 JS 实现乐观更新的关键三步
以“删除一条待办任务”为例，典型流程如下：
- 用户点击删除按钮 → 立即从 DOM 中移除对应
<li>元素（UI 更新） - 同时发起
fetch('/api/todos/123', { method: 'DELETE' }) - 若请求失败，在 catch 块中把刚才删掉的
<li>重新插回去（或还原其display: none状态）
注意：不能只靠 innerHTML 重写整个列表，否则会丢失焦点、滚动位置或临时输入状态。推荐用 element.remove() + 保留引用的方式做可逆操作。
立即学习“前端免费学习笔记（深入）”；
容易被忽略的回滚细节
乐观更新最常崩在“怎么准确还原”这一步。以下情况必须提前考虑：
- DOM 节点被删后，若未保存原始
outerHTML或节点引用，就无法真正“恢复”，只能 reload 页面 - 如果删除前该条目有正在编辑的
<input>，直接 remove 会导致输入内容丢失；应先blur()并缓存value - 服务端返回 409（冲突）或 403（无权限）时，仅靠 HTTP 状态码不够，需检查响应体中的
error.code字段决定是否回滚（比如 403 可能不该回滚，而是提示权限不足） - 多个并发乐观操作（如连点两次删除）可能造成状态错乱，建议加
isOptimisticUpdating标志位锁住按钮
不推荐用 innerHTML 或 outerHTML 做乐观更新
虽然看起来简单，但隐患明显：
-
element.innerHTML = newHtml会销毁所有子节点绑定的事件监听器，包括自定义的click、input -
element.outerHTML = ...本质是 replace，触发父节点重排，可能引发意外滚动或动画中断 - 服务端返回的数据结构若与本地缓存不一致（比如新增了
updatedAt字段），直接塞outerHTML会覆盖掉你刚改的 UI 状态
真正可控的做法是：用 dataset 存 ID，用 cloneNode(true) 缓存节点，用 insertBefore 或 append 精确还原位置。
