前端表单联动校验失效排查：旧状态、重复提交和提交锁

前端表单最容易出问题的地方，往往不是单个输入框，而是字段之间的联动。比如套餐类型变了，优惠码规则也要跟着变；用户快速连点提交按钮时，接口还可能被发起两次。

这篇文章用一次真实开发中常见的排查过程来讲：为什么表单明明改了字段，校验却还在用旧状态？为什么按钮已经点过一次，接口还是被重复提交？最后我们用派生规则、同步校验和提交锁把问题收住。

问题现场：字段已经改变，校验仍然报错

我们先看现象。用户打开订单表单，先选择“月付套餐”，输入优惠码 YEAR20。后来把套餐切换成“年付套餐”，这个优惠码本来应该可用，但点击提交后仍然提示“不匹配”。更麻烦的是，用户连续点了两下提交按钮，网络面板里出现了两次请求。

这个现象暴露出两个问题：

• 校验规则没有跟着套餐类型及时更新，导致使用旧状态判断。
• 提交过程中按钮没有锁住，用户重复点击后发起了多次请求。

初步判断：是不是接口规则写错了

第一反应通常是怀疑后端接口规则有问题。但我们先不要急着改接口，先看请求参数。开发者工具里能看到两次请求都带了同样的套餐类型和优惠码，服务端只是按收到的数据返回 400。

{
  "planType": "year",
  "couponCode": "YEAR20"
}

如果接口规则确实允许年付套餐使用 YEAR20，那问题更可能出在前端提交前的校验和状态同步。接着我们用一段小代码复现。

动手验证：最小代码复现旧状态

下面这段写法很常见：输入改变时先更新状态，提交时再读取当前状态校验。

let form = {
  planType: "month",
  couponCode: ""
};

function onPlanChange(nextPlan) {
  form.planType = nextPlan;
}

function checkCoupon() {
  if (form.planType === "month" && form.couponCode === "YEAR20") {
    return "月付套餐不能使用 YEAR20";
  }
  return "";
}

在简单对象里这段没问题，但在 React、Vue 或其他响应式框架中，状态更新和视图更新都有自己的调度过程。如果校验规则被提前缓存，或者提交函数闭包里拿到的是旧表单对象，就会出现“页面看起来变了，校验还按旧值跑”的错觉。

再看重复提交。很多代码只在请求结束后显示结果，却没有在请求期间锁住按钮：

async function submitForm() {
  const error = checkCoupon();
  if (error) {
    showError(error);
    return;
  }

  await request("/api/order/submit", form);
  showSuccess("提交成功");
}

这段代码的问题是：第一次请求还没回来，第二次点击又进来了。

定位原因：规则、状态和提交时机没有对齐

现在可以定位到两个根因。

第一，校验规则不应该单独保存一份容易过期的副本。它应该从当前表单状态派生出来。套餐类型变了，优惠码规则就应该同步变化。

第二，提交函数需要一个明确的请求中状态。只要请求正在进行，就应该禁用按钮或直接忽略后续点击，避免同一份表单被重复提交。

修复方案：派生校验和提交锁

修复时，我们把规则变成一个函数，始终从最新表单值计算；提交时加一个 submitting 锁，锁住期间按钮不可点。

function getCouponError(form) {
  if (form.planType === "month" && form.couponCode === "YEAR20") {
    return "月付套餐不能使用 YEAR20";
  }
  return "";
}

let submitting = false;

async function submitForm(form) {
  if (submitting) {
    return;
  }

  const error = getCouponError(form);
  if (error) {
    showError(error);
    return;
  }

  submitting = true;
  try {
    const result = await request("/api/order/submit", form);
    showSuccess(result.message || "提交成功");
  } finally {
    submitting = false;
  }
}

如果是组件代码，按钮状态也要绑定这个锁：

  提交

注意：提交锁不是替代后端幂等。它只能减少前端重复点击，真正涉及下单、支付、领券时，后端仍然要用幂等键兜底。

验证结果：只发起一次请求

修复后，我们按三个步骤验证：

1. 切换套餐类型，再输入优惠码，错误提示能立刻跟随变化。
2. 快速连续点击提交按钮，网络面板里只出现一次请求。
3. 请求失败或成功后，按钮恢复可点击，不会永久锁死。

如果这三点都满足，说明校验和提交时机已经对齐。后续再配合后端幂等，整条链路就更稳。

总结清单

• 联动字段的校验规则尽量从当前状态派生，不要复制一份容易过期的规则。
• 输入变化后立即同步校验，让页面提示和真实提交规则保持一致。
• 提交函数开头检查提交锁，锁住期间忽略后续点击。
• 按钮禁用状态要和提交锁一致，给用户清晰反馈。
• 请求结束后必须释放锁，失败分支也不能漏掉。
• 关键业务接口仍然需要后端幂等，前端锁只能降低重复点击概率。

这次排查的核心是：表单状态、校验规则和提交时机必须绑定在同一条链路里。只要其中一个环节使用旧值，页面就会出现看似随机的错误；只要提交过程没有锁，用户连点就可能制造重复请求。把规则派生化、校验同步化、提交流程加锁，前端表单会稳定很多。