一、场景引入：为什么表单校验总在"最后一步"出问题

做支付宝小程序开发时，表单提交是最常见的功能之一。不管是登录、注册、下单、填写收货地址，还是提交反馈，本质上都是"用户填一堆输入框，点一下按钮，数据传到后端"。但实际开发中，你会发现一个很普遍的现象：用户在页面上折腾了半天，最后点提交，要么弹个"必填项不能为空"，要么服务端报个"手机号格式不正确"。用户烦，开发者也烦。

出现这种问题，通常不是后端接口写得不好，而是前端在"表单提交验证"这块没有做细。很多人觉得校验不就是"非空判断"加"正则匹配"吗？真做起来才发现，场景一变，规则就乱。比如同一个输入框，在新增时是必填，在编辑时可填可不填；同一个手机号，在登录页要校验运营商号段，在绑定时又要校验是否已被使用。如果每个页面都复制一套校验代码，维护起来就是灾难。

这篇文章不跟你聊那些高深的概念，就用最实在的写法，把支付宝小程序里不同场景下表单校验的逻辑怎么组织、异常反馈怎么提示，一步步拆开讲清楚。所有示例统一用支付宝小程序的标准技术栈——JavaScript +支付宝小程序原生API，你可以在自己项目里直接照着改。

二、先搞清楚：支付宝小程序的表单校验和普通网页有什么不一样

2.1 没有DOM操作，取值靠数据绑定

在网页里，你可以用 document.getElementById('phone').value 去拿输入框的值。但在支付宝小程序里，没有 document，也没有 window。你必须在页面的 data 里定义一个对象，比如 formData，然后通过 input 事件实时更新 formData 里的字段。

2.2 校验时机不同

普通网页可能用 blur（失焦）事件去触发单个字段校验。支付宝小程序也支持 onBlur，但要注意：有些场景下用户还没填完就滑走了，失焦校验不一定及时。更稳妥的做法是"提交时统一校验 + 关键字段失焦时提示"。

2.3 弹窗组件有限

网页可以用 alert、toast、自定义弹窗。小程序里只推荐三种反馈方式：my.showToast（轻提示）、my.alert（带确定按钮的对话框）、my.showModal（带确认和取消）。如果你把校验错误信息用长篇大论塞进 my.showToast，用户根本看不完。所以异常反馈要分级别：单个字段的错误提示用「红字 + 轻提示」，整体提交失败用「模态框」。

三、基础场景：最普通的表单提交校验怎么写

我们先从最简单的场景入手：一个登录表单，只有手机号和密码，要求手机号必填且格式正确，密码必填且不少于6位。

3.1 页面结构（AXML）

<!-- login.axml -->
<view>
  <input
    name="phone"
    placeholder="请输入手机号"
    onInput="handleInput"
    data-field="phone"
    maxlength="11"
  />
  <input
    name="password"
    placeholder="请输入密码"
    password="true"
    onInput="handleInput"
    data-field="password"
  />
  <button type="primary" onTap="handleSubmit">登录</button>
  <!-- 显示提交中的状态 -->
  <view a:if="{{submitting}}">提交中...</view>
</view>

3.2 页面逻辑（JavaScript）——技术栈：JavaScript + 支付宝小程序原生API

Page({
  // 表单数据都放在data里
  data: {
    formData: {
      phone: '',
      password: ''   // 临时存储，不用于展示
    },
    submitting: false // 防止重复提交
  },

  // 统一处理输入事件
  handleInput(e) {
    const field = e.currentTarget.dataset.field; // 从事件对象上取出字段名
    this.setData({
      [`formData.${field}`]: e.detail.value // 动态更新对应字段
    });
  },

  // 单个字段的校验规则，返回错误信息字符串，没有错误就返回空串
  validateField(field, value) {
    const phoneReg = /^1[3-9]\d{9}$/; // 简单手机号规则
    switch (field) {
      case 'phone':
        if (!value) return '手机号不能为空';
        if (!phoneReg.test(value)) return '手机号格式不正确';
        return '';
      case 'password':
        if (!value) return '密码不能为空';
        if (value.length < 6) return '密码至少6位';
        return '';
      default:
        return '';
    }
  },

  // 提交前整体校验，返回第一个错误信息
  validateAll() {
    const { formData } = this.data;
    // 按顺序遍历，哪个字段先错就先提示哪个
    const fields = ['phone', 'password'];
    for (let i = 0; i < fields.length; i++) {
      const field = fields[i];
      const errorMsg = this.validateField(field, formData[field]);
      if (errorMsg) return errorMsg; // 出错立即返回
    }
    return ''; // 全部通过
  },

  handleSubmit() {
    if (this.data.submitting) return; // 防止连点
    const errorMsg = this.validateAll(); // 整体校验
    if (errorMsg) {
      // 用一个轻提示反馈给用户
      my.showToast({
        type: 'fail',
        content: errorMsg,
        duration: 2000
      });
      return;
    }
    // 通过校验后，模拟提交
    this.setData({ submitting: true });
    // 这里假装调了后端接口
    setTimeout(() => {
      my.showToast({ type: 'success', content: '登录成功' });
      this.setData({ submitting: false });
      // 实际项目里会调用 my.navigateBack() 或跳转页面
    }, 1000);
  }
});

你看，这样写其实逻辑很清楚：输入事件只负责更新数据，校验规则独立成方法，提交时统一调用。特别要注意 setData 里用了动态属性名 [`formData.${field}`]，这是支付宝小程序支持的写法，避免写一堆 if 分支去赋值。

3.3 这个方案的优缺点

优点：

  • 结构清晰，校验规则和页面渲染完全分离。
  • 成功或失败都走统一反馈通道，代码量小。
  • 适合字段少、规则简单的表单。

缺点：

  • 每个页面都要重复写 validateField 和 validateAll，表单一多就很烦。
  • 只提示第一个错误，用户改完第一个错误提交，才看到第二个错误，体验不够好。
  • 没有关联场景的判断，比如"手机号已注册"这种需要后端参与的校验，在这里做不到。

所以，一旦到了更真实的业务场景，基础版往往不够用。下面我们进入多场景的进阶设计。

四、进阶场景：动态表单、条件必填与自定义规则

实际项目里，表单很少是固定不变的。比如一个"请联系人信息"表单，如果用户勾选了"与其他地址相同"，那么手机号和详细地址就不是必填；如果选了"不同地址"，那这两个字段就变成必填了。还有更复杂的：用户选择"企业用户"时，需要多填一个"企业统一社会信用代码"，选择"个人用户"时，这个字段隐藏。

这种动态表单的校验，核心问题不是规则写不出来，而是"规则要随着页面状态变化"。

4.1 需求描述

一个活动报名页面，有两个选项：个人报名 和 团队报名。选择"团队报名"时，会出现一个"团队名称"输入框，并且这个输入框是必填的；选择"个人报名"时，团队名称隐藏且不校验。另外，不管哪种方式，都需要填手机号，但如果用户选择了"无需联系我"的单选框，手机号就不是必填了。

4.2 代码实现——技术栈：JavaScript + 支付宝小程序原生API

<!-- register.axml -->
<view>
  <radio-group onRadioChange="handleTypeRadio">
    <label>个人报名</label>
    <radio value="personal" checked="{{type === 'personal'}}" />
    <label>团队报名</label>
    <radio value="team" checked="{{type === 'team'}}" />
  </radio-group>

  <!-- 团队报名时才会显示团队名称 -->
  <view a:if="{{type === 'team'}}">
    <input
      name="teamName"
      placeholder="请输入团队名称"
      onInput="handleInput"
      data-field="teamName"
    />
  </view>

  <!-- 开关：是否需要联系 -->
  <switch checked="{{needContact}}" onChange="handleSwitch" />

  <view a:if="{{needContact}}">
    <input
      name="phone"
      placeholder="请输入手机号"
      onInput="handleInput"
      data-field="phone"
    />
  </view>

  <button onTap="handleSubmit">提交报名</button>
</view>

// register.js
Page({
  data: {
    type: 'personal',             // 当前用户类型
    needContact: true,            // 是否需要联系
    formData: {
      teamName: '',
      phone: ''
    }
  },

  handleTypeRadio(e) {
    this.setData({ type: e.detail.value });
  },

  handleSwitch(e) {
    this.setData({ needContact: e.detail.value });
  },

  handleInput(e) {
    const field = e.currentTarget.dataset.field;
    this.setData({ [`formData.${field}`]: e.detail.value });
  },

  // 动态校验：根据页面状态决定校验哪些字段
  validateAll() {
    const { type, needContact, formData } = this.data;

    // 规则数组：每一项是 [字段名, 是否必填, 错误提示]
    const rules = [];

    // 团队报名时，teamName 必填
    if (type === 'team') {
      rules.push(['teamName', '团队名称不能为空', '请输入团队名称']);
    }
    
    // 需要联系时，手机号必填且要校验格式
    if (needContact) {
      rules.push(['phone', '手机号不能为空', '手机号格式不正确']);
    }

    // 逐条执行
    for (let i = 0; i < rules.length; i++) {
      const [field, emptyMsg, formatMsg] = rules[i];
      const value = formData[field] || '';

      // 非空校验
      if (!value) return emptyMsg;

      // 格式校验：手机号如果非空就匹配，正则单独判断
      if (field === 'phone' && !/^1[3-9]\d{9}$/.test(value)) {
        return formatMsg;
      }
    }
    return '';
  },

  handleSubmit() {
    const errorMsg = this.validateAll();
    if (errorMsg) {
      my.showToast({ type: 'fail', content: errorMsg });
      return;
    }
    my.showToast({ type: 'success', content: '报名成功' });
    // 这里再做真实提交
  }
});

这里有一个很关键的编码习惯：把"是否必填"和"格式校验"拆开。先判断空值，再判断格式。很多人喜欢写一个特别长的正则包含空值判断，比如 /^$|^1[3-9]\d{9}$/，这样写容易漏掉"必填"提示和"格式错误"提示之间的区别。现在拆开，用户能明确知道自己到底是没填，还是填错了。

4.3 动态表单校验的优缺点

优点：

  • 只校验当前状态下可见且必要的字段，逻辑不会自相矛盾。
  • 规则存储为数组，方便后续扩展。

缺点：

  • 如果字段特别多（20个以上），validateAll 里的规则数组还是会很长，不够优雅。
  • 没有把"每个字段的独立校验方法"抽出来，不符合单一职责。但这也无妨，因为小程序页面本身就不适合过度设计。

五、坑点解析：支付宝小程序表单校验的常见陷阱

你以为上面这些代码就够用了吗？我告诉你，真上线后还会碰到下面这些坑，每一个都能让用户抓狂。

5.1 坑点一：input的value没有及时更新

你在 handleInput 里使用 setData 更新数据，但如果你用 e.detail.value 去判断某些情况（比如输入框是否达到最大长度），请记住，这个值是实时的，但你的 data 里可能还没更新完。在小程序里，setData 是异步渲染的，但 e.detail.value 本身是同步的。所以在 handleInput 里直接去拿 this.data.formData.phone 可能拿到上一次的值。遇到这种问题，别犯迷糊，直接用 e.detail.value 就行。

5.2 坑点二：按钮连点导致重复提交

如果用户快速点击提交按钮两次，你的 handleSubmit 会被执行两次。第一层防护是 submitting 标志位，但这也有一个问题：如果提交失败，你必须把 submitting 重置为 false，否则按钮永远禁用。我建议把重置逻辑放到 finally 里，但小程序没有 try...finally 吗？有的，放进去就行。或者你可以在提交成功后跳转页面，这样就不存在重复点击了。

5.3 坑点三：modal弹窗的异步回调

如果你用 my.showModal 来让用户二次确认某个信息，比如"该手机号已绑定其他账号，是否继续？"，这个弹窗的回调是异步的。不要在弹窗外面就直接校验，要在 success 回调里继续。很多新手容易在 showModal 前后同时执行了提交逻辑，结果弹窗还没点，请求已经发出去了。

5.4 坑点四：正则表达式在不同手机上的兼容性

支付宝小程序的 JavaScript 引擎在某些老版本上对正则的某些特性支持不完整。比如正则里的 ?<=（正向预查）在旧安卓机上可能报错。建议尽量使用普通的 exec 或 test，不要使用过于复杂的正则。

六、异常反馈的细节设计：让用户知道"哪里错了，怎么改"

校验逻辑只是确定"有没有错"，真正让用户感受到专业度的，是异常反馈。下面从三个层面说清楚怎么反馈。

6.1 字段级别的提示

最好的体验是：在错误的输入框下方显示一行红字，而不是只弹一个toast。因为用户看完toast还得自己去猜哪个框错了。用支付宝小程序实现起来也不复杂，你在 data 里加一个 errors 对象，存储每个字段的错误信息，在模板里渲染出来。

<!-- 单字段校验演示 userform.axml -->
<view>
  <input
    name="email"
    placeholder="请输入邮箱"
    onInput="handleInput"
    data-field="email"
  />
  <text a:if="{{errors.email}}" style="color:#ff0000;font-size:24rpx;">
    {{errors.email}}
  </text>
</view>

// userform.js
Page({
  data: {
    formData: { email: '' },
    errors: {}   // 错误信息对象
  },
  handleInput(e) {
    const field = e.currentTarget.dataset.field;
    const value = e.detail.value;
    this.setData({
      [`formData.${field}`]: value
    });
    // 每次输入时，实时清空当前字段的错误提示
    this.setData({
      [`errors.${field}`]: ''
    });
  },
  validateField(field) {
    const value = this.data.formData[field] || '';
    if (field === 'email') {
      if (!value) return '邮箱不能为空';
      if (!/^[\w-]+(\.[\w-]+)*@[\w-]+(\.[\w-]+)+$/.test(value)) return '邮箱格式不对';
    }
    return '';
  },
  handleSubmit() {
    const field = 'email';
    const error = this.validateField(field);
    const errors = {};
    if (error) {
      errors[field] = error;
      this.setData({ errors }); // 把错误显示在输入框下方
      return;
    }
    my.showToast({ type: 'success', content: '提交成功' });
  }
});

这里有一个小技巧：输入框的 onInput 事件里主动清除错误提示。这样用户一修改，红字立刻消失，不需要等到下一个校验动作。交互上会感觉轻松很多。

6.2 整体级别的反馈

如果字段校验都通过了，但后端返回"用户名已存在"这种业务错误，这时候最好用 my.showModal，因为这种错误需要用户明确知道并做出下一步选择。比如：

// 接口返回错误码1101，表示用户名已存在
my.request({
  url: 'https://yourdomain.com/register',
  data: { username: this.data.formData.username },
  success: (res) => {
    if (res.data.code === 1101) {
      my.showModal({
        title: '注册失败',
        content: '该用户名已被占用，是否换一个？',
        confirmText: '去换一个',
        success: (result) => {
          if (result.confirm) {
            // 聚焦到用户名输入框
            this.setData({ focusUserName: true });
          }
        }
      });
    }
  }
});

6.3 提交中状态：防止用户焦虑

按钮上显示"提交中..."是必须的，同时把按钮禁用，避免重复点击。支付宝小程序里可以直接在 button 上加 disabled 属性。

<button disabled="{{submitting}}" onTap="handleSubmit">
  {{submitting ? '提交中...' : '提交'}}
</button>

七、关联技术：表单数据的预处理与格式化

做校验之前，有些字段最好先做标准化处理。比如手机号用户输入了空格，比如金额字段用户输入了"100.00"带逗号，比如身份证号带X大小写不一致。这些如果不在前端先整理干净，到后端就会导致校验失败，最终反馈的还是后端错误，体验极差。

一个常见的做法是：在 handleSubmit 里，先对 formData 进行归一化，再执行校验。举个例子：

// 归一化函数
normalizeData(formData) {
  const data = {};
  // 遍历所有字段，去除首尾空格，数字类型转成数字
  for (const key in formData) {
    let value = formData[key];
    if (typeof value === 'string') {
      value = value.trim();  // 去掉首尾空格
    }
    data[key] = value;
  }
  return data;
}

然后在 handleSubmit 里先调用它：

handleSubmit() {
  // 先归一化，再存回data
  const normalized = this.normalizeData(this.data.formData);
  this.setData({ formData: normalized });
  // 之后再校验
  const errorMsg = this.validateAll();
  if (errorMsg) return;
  // 继续提交...
}

这种前置处理非常实用，尤其是用户在粘贴手机号的时候，经常会带一个空格或者换行。不用做过多的提醒，直接静默处理掉。

八、特殊场景：异步校验（验证码、唯一性检查）

表单里经常有条件验证，比如验证码输入是否正确，或者邮箱是否已被注册。这类校验必须发请求问后端才能知道结果，不能在本地用正则判断。异步校验有一个关键问题：如何在提交时等待所有异步校验完成再决定是否提交？

下面用一个具体例子说明：注册表单，需要校验邮箱是否被占用。我们通过 my.request 发送请求，然后根据返回结果决定是否继续。

8.1 实现方案——技术栈：JavaScript + 支付宝小程序原生API

// asyncRegister.js
Page({
  data: {
    formData: {
      email: '',
      verification: ''  // 验证码，假设是纯数字6位
    },
    checking: false, // 是否正在校验邮箱
    emailChecked: false // 邮箱是否已经过唯一性检查
  },

  // 模拟请求后端：邮箱是否占用
  checkEmail(email) {
    return new Promise((resolve) => {
      // 实际项目中这里替换成 my.request
      setTimeout(() => {
        // 假设只有 test@qq.com 是占用的
        const occupied = email === 'test@qq.com';
        resolve({ occupied: occupied });
      }, 500);
    });
  },

  // 模拟请求后端：校验验证码是否正确
  checkCode(code) {
    return new Promise((resolve) => {
      setTimeout(() => {
        // 假设验证码必须是123456
        resolve({ correct: code === '123456' });
      }, 300);
    });
  },

  handleSubmit() {
    const { email, verification } = this.data.formData;
    // 本地基本格式校验
    if (!email) {
      my.showToast({ type: 'fail', content: '邮箱不能为空' });
      return;
    }
    if (!/^[\w-]+(\.[\w-]+)*@[\w-]+(\.[\w-]+)+$/.test(email)) {
      my.showToast({ type: 'fail', content: '邮箱格式不对' });
      return;
    }
    if (!verification) {
      my.showToast({ type: 'fail', content: '验证码不能为空' });
      return;
    }

    // 如果已经有异步校验结果，直接使用；否则先校验
    this.setData({ checking: true });
    const promiseList = [];

    // 1. 邮箱占用校验
    if (!this.data.emailChecked) {
      promiseList.push(
        this.checkEmail(email).then((res) => {
          if (res.occupied) {
            this.setData({ emailChecked: false });
            throw new Error('该邮箱已被注册');
          }
          this.setData({ emailChecked: true });
        })
      );
    }

    // 2. 验证码校验
    promiseList.push(
      this.checkCode(verification).then((res) => {
        if (!res.correct) {
          throw new Error('验证码不正确');
        }
      })
    );

    // 用Promise.all等待全部校验完成
    Promise.all(promiseList)
      .then(() => {
        my.showToast({ type: 'success', content: '所有校验通过，提交注册' });
        // 这里执行真正提交
        this.setData({ checking: false });
      })
      .catch((err) => {
        my.showToast({ type: 'fail', content: err.message || '校验失败' });
        this.setData({ checking: false });
      });
  },
});

这里的要点在于：把每一个异步校验都包装成 Promise，然后用 Promise.all 并行等待所有异步操作完成。如果其中任何一个抛错，整个提交流程就中断，用 catch 统一提示。这样一个页面里即使有多个异步校验，也不会出现"邮箱还没查完，验证码却提交了"的竞态问题。

8.2 异步校验的注意事项

  • emailChecked 这个标志位非常关键。如果用户修改了邮箱，之前检查的结果就作废。所以要在 handleInput 里把 emailChecked 重置为 false。
  • 如果有5个异步校验，Promise.all 是同时发出去的，不是一个个等着，响应速度更快。但如果后端接口限制了并发数，就要改成串联执行。简单串联可以用 async/await 配循环，这里就不再展开。

九、自研一个小型校验工具库（可选）

如果你在一个项目里要写十几个表单，每次都复制粘贴 validateField 和 validateAll 确实难受。但要注意，支付宝小程序官方并没有内置表单校验插件，所以通常有两种选择：引入第三方库（比如 Vant 小程序的 Form 组件），或者自己写一个轻量工具。

这里不推荐为了一个表单校验就引入整个 UI 库，太重了。我们可以自己写一个很简单的工具，只解决"规则收集"和"错误输出"的问题。

先定义一组规则配置：

// utils/form-validator.js
// 技术栈：JavaScript + 支付宝小程序原生API
class FormValidator {
  constructor(rules) {
    // rules 是一个对象，键是字段名，值是规则数组
    // 例如：{ phone: ['required', 'phone'], password: ['required', 'min:6'] }
    this.rules = rules;
  }

  // 内置的校验方法
  validators = {
    // 必填
    required(value) {
      return value !== '' && value !== null && value !== undefined;
    },
    // 手机号
    phone(value) {
      return /^1[3-9]\d{9}$/.test(value);
    },
    // 邮箱
    email(value) {
      return /^[\w-]+(\.[\w-]+)*@[\w-]+(\.[\w-]+)+$/.test(value);
    },
    // 最小长度，如 min:6
    min(value, param) {
      return value.length >= parseInt(param);
    }
  };

  // 校验整个表单，返回 { isValid, errors }
  validate(formData) {
    const errors = {};

    for (const field in this.rules) {
      const ruleList = this.rules[field];
      const value = formData[field] || '';

      for (let i = 0; i < ruleList.length; i++) {
        const ruleName = ruleList[i];
        const [name, param] = ruleName.split(':');

        // 如果对应校验器存在，且校验失败
        if (this.validators[name] && !this.validators[name](value, param)) {
          errors[field] = this.getErrorMsg(name, field);
          break; // 一个字段只报第一个错误
        }
      }
    }

    return {
      isValid: Object.keys(errors).length === 0,
      errors: errors
    };
  }

  getErrorMsg(name, field) {
    const messages = {
      required: `${field}不能为空`,
      phone: `手机号格式不正确`,
      email: `邮箱格式不正确`,
      min: `${field}长度不足`
    };
    return messages[name] || '格式不正确';
  }
}

// 导出给页面使用
module.exports = FormValidator;

然后在你的页面里这样使用：

// 技术栈：JavaScript + 支付宝小程序原生API
const FormValidator = require('../../utils/form-validator');

Page({
  data: {
    formData: { phone: '', email: '' },
    errors: {}
  },
  handleSubmit() {
    // 定义规则
    const rules = {
      phone: ['required', 'phone'],
      email: ['required', 'email']
    };
    const validator = new FormValidator(rules);
    const result = validator.validate(this.data.formData);

    if (!result.isValid) {
      this.setData({ errors: result.errors });
      my.showToast({
        type: 'fail',
        content: '请检查表单填写是否正确'
      });
      return;
    }
    my.showToast({ type: 'success', content: '校验通过' });
  }
});

这个工具类虽然简单，但能解决80%的固定规则校验。它的优点是：规则用字符串配置，好维护，好扩展。缺点是：内置规则不够多，比如"正则自定义"、"与另一个字段比较"这种还得自己加。不过没关系，你可以按需往 validators 里加方法。

十、多场景表格：什么时候用哪种校验方式

下面把前面提到的几种方式汇总对比一下，方便你根据项目情况选型。

场景 推荐方式 原因
2-3个字段的简单表单 手写 validateAll 逻辑简单，无需额外抽象
字段多且规则固定的表单 自研 FormValidator 工具类 减少重复代码
表单字段显隐随选项变化 动态配置规则数组 跟随页面状态，灵活
需要后端校验（唯一性、验证码） Promise.all 异步校验 保证所有校验完成后提交
需要字段级红字提示 errors 对象绑定到模板 提升用户体验

十一、注意事项总结

11.1 不要在点击提交时把所有错误一次性弹出来

有些开发者觉得，把所有错误都放在一个弹窗里，列出"1.手机号不对 2.邮箱不对 3.密码太短"，看起来很负责。但实际用户看到一堆堆文字会不知所措。更好的是：在表单下方或字段下方用红字标出具体错误，并在顶部用toast简单说一句"请检查标记项"。这样既不打扰，信息又完整。

11.2 密码类字段不要用 showToast 明文显示

用 my.showToast 显示"密码不能为空"没问题，但如果你希望在提示里带上用户输入的密码，那是大忌。所有反馈信息里不要包含用户的敏感输入。

11.3 注意校验和提交的时序

如果提交按钮上做了 submitting 的禁用，一定要在请求结束（成功或失败）后把 submitting 置回 false。如果你用 my.request，请在 complete 回调里重置，因为 complete 无论成功失败都会执行。

11.4 防止用户提交前的"隐藏字段"

如果一个输入框因为 a:if 被隐藏了，它的值仍然保留在 data.formData 里。你在校验的时候要额外判断这个字段是否可见。上面动态表单的例子里，通过在规则数组里只push可见字段来解决，这是一个安全做法。

11.5 正则测试要在真机上验证

有些正则编辑器里跑得好好的，但转成小程序代码后可能因为特殊字符转义出问题。例如 \d 在字符串里要写成 \\d。我在真实的项目里遇到过，拿出来专门提醒一下。

十二、结尾思考：表单校验的"度"在哪里

表单校验做轻了，用户容易填错，后端接口被无谓地调用；做重了，用户会觉得烦，每敲一个字母都要被提示。这个平衡点在哪里？

我的建议是：硬规则用前端校验，软校验用后端反馈。什么是硬规则？手机号格式、必填、密码最短长度，这些不随场景变化，前端可以直接拦下。什么是软校验？比如"用户名是否优雅"、"地址是否详细"，这些不应该在前端校验，因为前端根本判断不了，建议交给后端做逻辑判断，再返回明确提示。

在设计一个表单校验方案之前，先列清楚：哪些必须前端拦，哪些可以放给后端。一旦想清楚，你写的代码自然会更加清爽，用户在操作时也会觉得"这个程序好懂我"。

十三、文章总结

这篇内容从最简单的非空校验，到复杂动态表单的条件校验，再到异步校验的并发控制，把支付宝小程序表单提交验证的常见场景完整过了一遍。核心要点可以归结成四句话：数据统一管理、规则与页面分离、异常反馈分级别、异步校验用Promise。另外，不要为了炫技引入复杂框架，够用就好。工具类能解决重复劳动，但过度抽象同样会让阅读代码的人头疼。

每一类校验方案都有它的适用场景和限制，选择时优先考虑"维护成本"和"用户的真实操作体验"。如果下次你在开发中遇到"表单校验到底怎么写"的困惑，不妨回头看看这篇文章里的几个示例，把基础代码往自己的项目里一套，再根据需求改改规则，基本就能解决大多数问题。真正难的往往不是技术，而是想明白"什么时候该拦，什么时候该放"。希望这篇内容能帮你少踩几个坑，多写出几行不那么糟糕的代码。