HTML5无原生唯一请求ID属性，防重复提交需前后端协同：服务端生成绑定session的UUID，前端仅携带；离线时存IndexedDB并建唯一索引，同步时后端幂等校验+时效管理；UI层须禁用按钮并提示“已加入同步队列”。
HTML5 中没有“唯一请求 ID”这个原生属性，也不存在离线场景下靠单个 HTML 属性就能防重复提交的机制。所谓“通过唯一请求 ID 防止重复提交”，本质是前后端协同设计的业务逻辑，不是 HTML5 的功能特性。
唯一请求 ID 是服务端生成的业务标识
它通常是一个 UUID 或时间戳+随机数拼接的字符串，由后端在用户打开表单页时生成并下发，前端通过隐藏字段或 JS 变量持有。关键点在于：
- ID 必须每次页面加载都刷新，不能缓存或复用
- ID 要绑定当前用户 session 和当前表单类型（比如“创建订单”专用）
- 前端不生成、不修改、不猜测该值，只负责携带提交
离线场景中，ID 需配合 IndexedDB 存储与同步策略
当应用支持离线操作（如 PWA），用户在无网状态下填写并“提交”，实际是把数据连同 request_id 一起写入 IndexedDB。后续联网时再批量同步。此时防重逻辑要分两层：
-
本地层：在 IndexedDB 对象存储中，为 request_id 字段建立唯一索引（
createIndex('by_request_id', 'request_id', { unique: true })）。插入前若已存在相同 request_id，浏览器直接抛 ConstraintError，避免本地重复记录 - 服务端层：同步时将 request_id 作为请求头或参数传给后端；后端收到后先查数据库是否已处理过该 ID，已存在则跳过执行，返回成功响应（幂等）
不能只靠 ID，必须搭配状态标记与清理机制
光有 request_id 不够，还必须管理它的生命周期：
- 后端验证通过后，立即将该 ID 写入 Redis 或数据库，并设短时效（如 10 分钟）
- 同步失败时，前端需保留 request_id 和原始数据，直到成功且收到明确业务确认（如 response.code === 0）才从 IndexedDB 删除
- 若用户反复离线提交同一表单，应生成新 request_id（每次打开页面都重新获取），旧 ID 在超时后自动失效
前端提交动作本身仍需即时防护
即使有 request_id，用户在页面上快速连点提交按钮，仍可能触发多次“写库”操作。所以 UI 层必须同步做：
- 监听 form 的 submit 事件，在回调开头立即禁用所有 type="submit" 按钮
- 写入 IndexedDB 成功后才允许解锁按钮（而不是等网络同步完成）
- 显示“已加入同步队列”而非“提交成功”，避免用户误以为没生效而重试
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
