报名表单填到一半退出，回来数据还在吗：H5 表单草稿的自动保存与多端恢复

用户在活动报名 H5 里填了姓名、手机号、选好了场次，接个电话、切个后台，回来页面一刷新，全没了，只能重填。对报名、预约、问卷这类以收集信息为目的的 H5 来说，这是填写中断率最高的场景之一。

本篇讲 H5 表单草稿怎么做：本地自动保存、退出恢复、多端同步、以及"草稿覆盖正式数据"这类冲突怎么防，文末附可抄走的草稿保存与恢复代码模板。

一、为什么要自动保存草稿，而不是等用户点提交

用户填长表单的时间可能长达几分钟，期间任何一次意外（切后台被杀、误刷新、浏览器崩溃）都会丢数据。与其让用户"记得先保存"，不如在输入变化后防抖自动保存——既覆盖绝大多数丢失场景，又不会因为每敲一个字就写一次而增加性能负担。

另一个价值是跨端接续：用户在手机填了一半，换到电脑继续填同一场报名，能接上上次的内容，而不是从零再来。

二、本地草稿怎么存：localStorage 的方案与边界

同源下的首选是 localStorage，容量约 5MB，持久、无过期。存一份"表单快照 + 更新时间 + 表单版本号"：

var DRAFT_KEY = 'draft_' + formId;

function saveDraft(formData) {
  localStorage.setItem(DRAFT_KEY, JSON.stringify({
    data: formData,
    updatedAt: Date.now(),
    version: formVersion
  }));
}

保存时机用防抖：输入事件触发后 300ms 内没有新输入，才写一次，避免高频写入。多个表单各自独立 key，互不干扰。

要注意边界：隐私模式下 localStorage 可能不可用；多标签页同时编辑同一表单会互相覆盖；超过容量上限时写入会抛异常。因此 localStorage 只当"本机快速恢复"用，跨设备恢复必须走后端草稿。

三、刷新、切后台、杀进程后，回来怎么自动恢复

页面加载时先尝试恢复：有本地草稿且时间新于"已提交时间"，则回填表单并提示"已恢复上次未填写完的内容"。恢复要分字段处理：普通文本直接回填，文件上传类（图片、附件）本地只存了引用，恢复时提示重新选择或走服务端临时文件。

function restoreDraft(formId) {
  var raw = localStorage.getItem('draft_' + formId);
  if (!raw) return null;
  var draft = JSON.parse(raw);
  if (draft.submittedAt && draft.submittedAt > draft.updatedAt) {
    return null; // 已提交，草稿作废
  }
  return draft.data;
}

判断"该不该恢复"的关键是草稿时间 vs 提交时间：提交成功后要立刻记录 submittedAt，否则用户下次进页面会把旧草稿当新数据回填。

四、多端恢复怎么做：服务端草稿的落库与合并

跨设备恢复需要把草稿同步到服务端。设计上草稿和正式提交共用一张表，用 status 区分：

CREATE TABLE form_submission (
  submit_id    BIGINT PRIMARY KEY,
  form_id      BIGINT NOT NULL,
  user_token   VARCHAR(64) NOT NULL,     -- 游客用设备指纹，登录用户用账号
  payload      JSON NOT NULL,            -- 表单快照
  status       VARCHAR(16) NOT NULL,     -- draft/submitted
  updated_at   DATETIME NOT NULL,
  submitted_at DATETIME,
  KEY idx_form_user (form_id, user_token)
);

取草稿接口按"同一表单 + 同一用户标识"取最新一条，用户在 A 端保存、B 端打开即可接续。

并发冲突要防：A、B 两端同时编辑，后保存的会覆盖先保存的。做法是草稿带 updated_at，恢复时若本地草稿新于服务端，就提示"检测到更新中的草稿，用哪一份？"由用户选择，而不是静默覆盖。

草稿还需要生命周期管理：超期未提交的草稿定期清理（例如 30 天），避免垃圾数据堆积；清理只针对 status=draft 且 updated_at 过期的行。

服务端保存的完整时序是：输入防抖触发 → 本地先写一份 → 异步调服务端保存接口 → 服务端用"表单 + 用户标识"做 upsert（存在则更新 updated_at 与 payload，不存在则插入）→ 返回最新时间戳 → 本地更新。整个流程对用户无感，网络失败也不阻塞输入，只是草稿停留在本地版本、下次同步。

function syncDraftToServer(formData) {
  callApi('save_draft', {
    formId: formId,
    payload: formData,
    userToken: getUserToken(),
    localUpdatedAt: getLocalUpdatedAt()
  }).then(function (res) {
    setLocalUpdatedAt(res.serverUpdatedAt); // 以服务端时间为准
  });
}

版本裁决统一以服务端时间为准：本地时间可能被用户改、跨时区可能不一致，因此恢复时比较的是"服务端草稿时间 vs 本地草稿时间"，两者都转成服务端返回的时间戳再做大小判断。

五、提交成功后，草稿怎么清理

提交成功那一刻必须把三处状态一起处理：清除本地草稿、把服务端草稿标记为 submitted、记录提交时间。漏掉任何一处，都会出现"提交完还能恢复出旧草稿"的错乱。

function afterSubmitSuccess() {
  var raw = localStorage.getItem(DRAFT_KEY);
  var draft = raw ? JSON.parse(raw) : { data: {} };
  draft.submittedAt = Date.now();
  localStorage.setItem(DRAFT_KEY, JSON.stringify(draft)); // 记提交时间，恢复时跳过
  callApi('mark_submitted', { submitId: submitId });
}

注意不是简单 removeItem：记一个 submittedAt 再保留，能避免用户提交后又改了内容、下次进页面时系统把提交前草稿误判为"未提交内容"。

六、踩坑清单

• 不防抖直接每次输入就写：高频写入卡顿，用 300ms 防抖。
• 恢复时不比对提交时间：提交后旧草稿回填，数据被覆盖。
• 只做本地草稿不做服务端：换设备无法接续。
• 多端草稿静默覆盖：必须带时间戳，冲突时让用户选择。
• 上传类字段存引用不存文件：恢复时提示重新选择或走服务端临时文件。
• 提交成功后不清理：下次进页面误恢复旧内容。
• 草稿无过期策略：draft 行无限堆积，需要定期清理。

七、工程落地建议

草稿保存封装成独立模块，对外提供 save、restore、clearAfterSubmit 三个方法，业务表单只声明"哪些字段参与草稿、上传字段单独处理"。本地与远端草稿统一以"更新时间"裁决，任何一端都不允许静默覆盖。测试覆盖：刷新恢复、杀进程恢复、多端冲突、提交后清理、草稿过期清理五类场景。

八、上线复盘清单

• 是否输入防抖自动保存（300ms）
• 恢复是否校验"草稿时间 > 提交时间"
• 服务端草稿是否按表单+用户唯一、取最新
• 多端冲突是否提示选择而非静默覆盖
• 提交成功后是否同时清理本地与远端草稿
• 是否配置草稿过期清理任务

常见问题 FAQ

报名表单填到一半退出，数据还能找回吗？

能。输入变化后防抖自动保存到本地，页面加载时若检测到未提交且时间新的草稿会自动回填，并提示已恢复上次未填写完的内容。

表单草稿换手机还能继续填吗？

需要服务端草稿支撑：草稿按"表单 + 用户标识"落库，换设备后取最新一条即可接续；两端同时编辑时按更新时间裁决，由用户选择用哪一份。

提交成功后，草稿会不会再被恢复出来？

不会。提交成功会记录提交时间并标记服务端草稿为已提交，恢复逻辑会跳过时间早于提交时间的旧草稿，避免旧数据覆盖正式提交。

结语

草稿机制的本质是"把用户填写过程中的中间态也当成一种数据来管理"：本地快速恢复 + 服务端跨端接续 + 时间戳裁决冲突，三层做完，填写过程就基本不会再丢。

隐私上还要注意：草稿里通常有姓名、手机号等个人信息，本地草稿建议在"退出登录/提交完成后"清理，服务端草稿字段做脱敏展示与访问控制，接口按表单 + 用户标识鉴权，避免他人拿到草稿接口遍历出用户信息。本文为工程实践分享，具体规则以各业务实际为准。