需后端提供revision_id等唯一标识供前端比对，提交前用fetch校验，409时提示并用sessionStorage暂存输入后reload恢复；仅靠timestamp或localStorage会因时钟偏差、并发写入等导致冲突检测失效。
怎么检测 HTML 表单是否被其他人同时编辑
HTML 本身不提供协作冲突检测能力，document 和 form 元素没有内置的“版本号”或“最后修改时间戳”。所谓“对方已修改”提示，必须靠后端配合前端主动实现——前端只负责比对、弹提示、阻止提交。
常见错误现象：onbeforeunload 被误用作冲突检测（它只管本机离开，不管别人改了没）；或仅靠本地 localStorage 记录时间戳，结果多人之间完全不同步。
- 必须由后端在每次读取表单数据时返回一个唯一标识，比如
revision_id或etag - 前端在加载表单时存下这个值，提交前带上它（作为请求头或字段），后端校验是否仍有效
- 如果后端发现该
revision_id已被覆盖，就返回409 Conflict+ JSON 提示，前端再触发警告
如何用 fetch 拦截 409 并显示“对方已修改”提示
这是最轻量、兼容性最好的落地方式，不需要框架或复杂状态管理。关键不是“怎么弹窗”，而是“怎么让弹窗内容可操作”——用户得能刷新并保留当前输入（否则一怒之下关掉页面，所有填写白费）。
使用场景：编辑页（如 /post/123/edit）加载后，用户填了一半，另一个人先保存成功，当前用户再点提交就会撞上冲突。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 提交前用
fetch发HEAD或带If-Match头的GET请求，提前探查revision_id是否过期 - 若响应是
409，从响应体中解析出最新修改人、时间等信息，用alert()或自定义 modal 显示，例如："张三 2 分钟前已更新，是否重新加载？" - 点击“重新加载”后，用
location.reload()，但务必先用sessionStorage把当前输入暂存，reload 后再恢复（注意避开敏感字段如密码）
为什么不能只靠 timestamp 或 localStorage 做冲突判断
看似简单的时间戳方案，在真实协作中几乎必然失效。问题不在代码写错，而在模型错了——它假设“谁改得晚谁赢”，但网络延迟、时钟偏差、多端登录会让这个假设崩塌。
性能 / 兼容性影响：用 Date.now() 做比对，开发时本地测不出问题，上线后只要两人设备时间差超过 2 秒，就可能误报冲突或漏报冲突。
-
localStorage是 per-origin 且同步阻塞的，无法跨标签页实时感知变更（storage事件有延迟，且不触发于同标签页） - 服务端若只存
updated_at时间，高并发下两个请求几乎同时写入，会得到相同时间戳，导致后写入者无法被识别为“冲突方” - 真正可靠的标识是服务端生成的单调递增
revision_id（如 PostgreSQL 的xmin、MongoDB 的ObjectId时间段、或自增 version 字段）
表单提交时如何安全地保留用户未保存的输入
冲突提示之后，用户大概率想看看别人改了啥，再决定要不要重填。这时候强制清空表单等于劝退。保留输入不是锦上添花，而是避免数据丢失的底线。
容易踩的坑：直接序列化整个 form 元素（会丢掉动态添加的字段、富文本内容、文件 input 状态）；或只存 value 忽略 checked/selected 状态。
- 遍历所有
form.elements，按类型分别提取：input[type=checkbox/radio]用checked，select用selectedIndex，textarea和普通input用value - 存入
sessionStorage时加前缀（如"draft-post-123-"），避免和其他页面冲突 - reload 后用
setTimeout(() => { /* 恢复逻辑 */ }, 0)确保 DOM 渲染完成再操作，否则某些框架（如 Alpine）可能尚未接管元素
事情说清了就结束。真正难的不是弹那个提示框，是让后端返回可比对的修订标识、以及在 reload 后把用户那堆没来得及提交的输入丝毫无损地塞回去——这两处一旦松懈，协作提示就从防错变成添堵。
