轻应用表单提交丢数据怎么办？表单可靠投递的三种方案与实战

轻应用表单提交丢数据怎么办？表单可靠投递的三种方案与实战

先说结论：表单提交丢数据，九成不是后端接口挂了，而是前端提交链路和入库逻辑缺了可靠性设计——弱网下请求失败被静默吞掉、后端没有幂等、写入没有补偿，三条缺一条就会丢。本文复盘一次 3000 人同时在线的考试报名事故：表单提交丢失率 3.2%，一天漏了 96 条报名；用"前端本地缓存重试 + 后端幂等流水表 + 定时补偿"三件套修完后，到达率稳定在 99.8%。下面把三种方案和代码完整拆开。

先说背景

客户的活动报名小程序跑在一套托管式建站的 SaaS 底座上，报名表单页面和基础数据由底座承载，日常没出过问题；这次提交丢数据，问题出在我们自己实现的前端提交链路和后端入库逻辑上，和底座本身无关。排查和修复过程完整复盘如下。

一、为什么表单提交会丢

一次表单提交的完整链路：用户点提交 → 前端发请求 → 后端写库 → 前端提示成功。这四步里任何一步出问题，用户看到的结果都一样——"没提交成功"或"提交了但没记录"。常见丢法有三种：

• 前端请求失败，静默吞掉，用户以为成功了（弱网下最常见）；
• 后端接口被重复提交打爆，前一次请求实际写库成功但响应超时，用户重试造成重复，或直接放弃；
• 后端写库失败，但没留任何补偿机制，数据就丢在中间状态。

定位方法也简单：给前端请求加全局 fail 埋点，给后端入库加流水日志，两边一对就知道丢在哪一段。前端埋点看有没有发出请求、失败了几次；后端流水看收到几条、写库成功几条。这次排查就是靠这个办法定位的：前端日志显示 3.2% 的请求进了 fail 回调，后端流水显示只有 96 条缺了对应记录——数据丢在前端重试环节，而不是后端。

二、方案一：前端本地缓存 + 重试队列（解决"请求失败被吞"）

前端是第一个丢数据的口子。弱网下 wx.request 的 fail 回调触发后，很多实现直接不管，用户看到的就是"提交没反应"或"提交成功但后台没有"。

// 提交前先写本地队列，失败自动重试，成功再移除
const pending = wx.getStorageSync('form_pending') || [];
function submitForm(form) {
  pending.push({ ...form, status: 'pending', ts: Date.now() });
  wx.setStorageSync('form_pending', pending);
  flushPending();
}

function flushPending() {
  const list = wx.getStorageSync('form_pending') || [];
  if (!list.length) return;
  wx.request({
    url: 'https://api.example.com/form',
    method: 'POST',
    data: { list },
    success: (res) => {
      if (res.statusCode === 200) {
        wx.setStorageSync('form_pending', []);
      }
    },
    fail: () => {
      // 下次启动或网络恢复后再试
      setTimeout(flushPending, 30000);
    },
  });
}

关键点：本地缓存是保险，不是主路径。它只解决"前端丢"，解决不了"后端重复"——所以必须有方案二兜底。

三、方案二：后端幂等 + 流水表（解决"重复提交"和"中间状态丢失"）

前端重试之后，后端可能收到同一笔提交多次。后端必须幂等：用业务唯一键（如 用户ID+活动ID+提交时间戳）去重，先查流水再写数据。

def submit_form(form):
    biz_key = f"{form['user_id']}:{form['activity_id']}:{form['ts']}"
    # 幂等：流水表里已有同 key，直接返回成功，不重复写
    if redis.exists(biz_key):
        return {'code': 0, 'msg': 'already_submitted'}
    # 两阶段：先记流水（状态=进行中），再写业务数据
    log_id = insert_form_log(biz_key, 'processing')
    try:
        insert_form_data(form)          # 真正的业务写入
        update_log_status(log_id, 'done')
        redis.setex(biz_key, 3600, '1')
        return {'code': 0}
    except Exception:
        update_log_status(log_id, 'failed')
        raise

-- 流水表：幂等键唯一索引 + 状态字段，供定时补偿扫描
CREATE TABLE form_log (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  biz_key VARCHAR(128) NOT NULL,
  status VARCHAR(16) NOT NULL,          -- processing / done / failed
  payload TEXT,
  created_at DATETIME NOT NULL,
  UNIQUE KEY uk_biz (biz_key)
) ENGINE=InnoDB;

幂等键设计是这节的核心：必须落在"用户+活动+提交时刻"这种业务唯一维度上，用时间戳当 key 的裸做法在弱网重试下照样重复。

四、方案三：定时补偿（解决"写库失败卡在中间态"）

两阶段里"先记流水、再写业务"会有中间态：流水是 processing、业务数据还没写进去，进程就崩了。靠用户重试永远补不齐，必须定时扫补偿。

# 每 5 分钟扫一次 processing 超过 60 秒的流水，重新执行业务写入
def compensate():
    stale = select_stale_logs(status='processing', older_than=60)
    for log in stale:
        try:
            insert_form_data(json.loads(log['payload']))
            update_log_status(log['id'], 'done')
        except Exception:
            update_log_status(log['id'], 'failed')  # 连续失败进告警，人工介入

三件套合起来才完整：前端重试保证"不丢"，后端幂等保证"不重"，定时补偿保证"不卡中间态"。少任何一件，可靠性都打了折扣。这套组合不挑语言和框架，Node、Python、Java 后端都能照这个结构落地，前端换成 uni-app 或原生小程序也只是把 wx.request 换成对应封装。

五、方案怎么选：不是每张表单都要上三件套

三件套是完整形态，但不是所有场景都值得全上，按业务价值分级：

1. 报名、预约、订单这类"用户交了钱/交了名额"的表单：三件套全上，丢一条都是事故；
2. 咨询、留言这类"可重复提交"的表单：前端重试 + 后端幂等就够，定时补偿可以不做（丢了用户会再发一次）；
3. 纯埋点、统计上报：本地缓存重试即可，允许小比例丢失，别把链路做复杂。

判断标准就一条：这条数据丢了，用户会不会投诉。会，就按最高标准做；不会，做轻量版，省下的开发量留给真正重要的链路。下面五个坑，全是实战里真实踩过的。

六、5 个实战踩坑

• 踩坑1：前端只在 fail 回调里 toast，不做本地缓存重试——弱网下 3.2% 的提交就是这么丢的，静默失败最可怕；
• 踩坑2：幂等键用纯时间戳，同秒两次请求照样重复入库；必须用 用户+活动+时间戳 组合；
• 踩坑3：后端先写业务数据再记流水，进程崩在中间，数据丢了连日志都没有；顺序必须是先流水后业务；
• 踩坑4：补偿任务扫全表没索引，5 分钟扫不完 10 万行；流水表加 status+created_at 联合索引后秒级；
• 踩坑5：前端重试没有退避，网络一抖 1000 个请求同时打后端；重试间隔指数退避（30s→60s→120s），峰值直接削平。

结语

表单提交可靠性是个系统工程：前端本地缓存重试解决"丢"，后端幂等流水解决"重"，定时补偿解决"卡"。这次事故从发现到修完用了一天，丢的 96 条报名靠流水表 + 用户反馈手动补齐；三件套上线后，后续两场活动（累计 6000 人次）提交到达率 99.8%，一次漏单都没有。表单是最基础的能力，也是最容易被忽视的可靠性盲区——先把这三件套焊上，比什么都强。