基于JavaScript策略模式的可扩展表单验证方案

一、传统表单验证的典型困境

在日常开发中，许多初学者或赶进度的项目常常直接在表单提交事件处理函数中书写校验逻辑。随着业务表单字段的增加，这种方式会迅速暴露严重的架构缺陷：

// 传统常见实现：逻辑混杂在提交事件中
const form = document.querySelector('#registerForm');

form.addEventListener('submit', function (event) {
  event.preventDefault();

  if (!form.userName.value.trim()) {
    alert('用户名不能为空');
    return;
  }
  if (form.password.value.length < 6) {
    alert('密码长度不能少于 6 位');
    return;
  }
  if (!/^1[3-9]\d{9}$/.test(form.phoneNumber.value)) {
    alert('手机号码格式不合规');
    return;
  }

  // 校验通过，发送网络请求
  sendFormData(form);
});

上述代码在面对简单需求时看似直观，但在工程化视角下存在三大核心问题：

• 违反单一职责原则（SRP）：表单提交监听函数承担了双重职责，既要负责事件监听、DOM 提取与后续提交，又要负责具体验证算法的细节实现。
• 缺乏复用性：“手机号正则”、“密码最小长度”等逻辑被硬编码锁死在该表单的回调中。当系统中出现“个人资料修改”、“找回密码”等其他表单时，开发者只能通过复制代码进行复用。
• 违反开闭原则（OCP）：当产品经理需要为密码增加“必须包含字母与数字”或调整长度限制时，必须直接深入修改整个提交处理函数内部的分支结构，极易引入回归缺陷。

二、策略模式的核心概念与角色划分

策略模式的定义是：定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。策略模式的目的就是将算法的使用与算法的实现分离开来。

在表单验证的语境下，一个完整的策略模式方案包含三个独立角色：

1. 策略集（Strategies）：封装了具体的验证算法纯函数，负责输入值的有效性裁定。若验证失败则返回对应的错误提示文案，若通过则不返回值或返回空。策略函数不持有任何 DOM 依赖或外部状态。
2. 环境上下文（Validator / Context）：验证调度器。它负责接收客户端的配置请求，内部维护一组待验证任务队列，并在触发时按序调用策略函数，对结果进行收集或中断拦截。
3. 客户端调用层（Client）：业务页面。负责向 Validator 提交验证规则配置，并在最终提交时触发执行并处理校验反馈。

三、基础策略验证器的分步实现

为了让架构落地，我们首先构建一个轻量且完整的原生 JavaScript 策略验证器。

步骤 1：定义具体策略仓库

策略仓库通常是一个键值对对象。每个属性名代表策略名称，属性值为接收 (value, errorMsg, ...params) 的纯函数：

// 策略算法仓库
const strategies = {
  // 非空校验
  isNonEmpty(value, errorMsg) {
    if (value === null || value.trim() === '') {
      return errorMsg;
    }
  },

  // 最小长度校验
  minLength(value, length, errorMsg) {
    if (value.length < Number(length)) {
      return errorMsg;
    }
  },

  // 手机号码格式校验
  isMobile(value, errorMsg) {
    const mobileReg = /^1[3-9]\d{9}$/;
    if (!mobileReg.test(value)) {
      return errorMsg;
    }
  },

  // 邮箱格式校验
  isEmail(value, errorMsg) {
    const emailReg = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
    if (!emailReg.test(value)) {
      return errorMsg;
    }
  }
};

步骤 2：封装验证调度类 Validator

调度类需要提供两项核心能力：利用 add 方法注册验证规则，以及利用 start 方法启动校验流水线。为避免过早读取输入框内容，add 必须将校验动作包装为闭包函数存入队列：

class Validator {
  constructor() {
    // 缓存所有待执行的校验函数闭包
    this.cache = [];
  }

  /**
   * 注册单个校验项
   * @param {HTMLElement} dom 表单输入控件
   * @param {string} strategyAndArgs 策略名称及参数，如 'minLength:6'
   * @param {string} errorMsg 验证未通过时的提示
   */
  add(dom, strategyAndArgs, errorMsg) {
    const argList = strategyAndArgs.split(':');

    this.cache.push(() => {
      const strategyName = argList.shift();
      const targetStrategy = strategies[strategyName];

      if (typeof targetStrategy !== 'function') {
        throw new Error(`未找到对应的校验策略: ${strategyName}`);
      }

      // 参数顺序调整为: (dom.value, ...自定义参数, errorMsg)
      const currentParams = [dom.value, ...argList, errorMsg];
      return targetStrategy.apply(dom, currentParams);
    });
  }

  /**
   * 启动校验流水线
   * 采用 Fail-Fast 机制：遇到第一个错误立即拦截并返回
   */
  start() {
    for (let i = 0; i < this.cache.length; i++) {
      const validatorFunc = this.cache[i];
      const errorMsg = validatorFunc();
      if (errorMsg) {
        return errorMsg;
      }
    }
  }
}

四、进阶演进：单字段多规则组合校验

在真实业务表单中，单个输入字段往往同时施加多重约束。例如密码字段既要求“不能为空”，又要求“长度不低于 8 位”，还要求“不能包含空格”。如果每个字段只能配置一条规则，实用性将大打折扣。

我们对 Validator.prototype.add 进行增强，使其支持传入规则配置数组：

// 增强版 Validator 类：支持单个 DOM 绑定规则列表
class AdvancedValidator {
  constructor() {
    this.cache = [];
  }

  /**
   * 支持批量传入规则配置
   * @param {HTMLElement} dom - 表单控件
   * @param {Array<{strategy: string, errorMsg: string}>} rules - 规则对象列表
   */
  add(dom, rules) {
    for (const rule of rules) {
      this.cache.push(() => {
        // 允许 strategy 使用冒号分割参数，例如 'minLength:8'
        const strategyAry = rule.strategy.split(':');
        const strategyName = strategyAry.shift();
        
        const strategyHandler = strategies[strategyName];
        if (!strategyHandler) {
          throw new Error(`校验策略未注册: ${strategyName}`);
        }

        // 构造实参列表: [value, ...args, errorMsg]
        const args = [dom.value, ...strategyAry, rule.errorMsg];
        return strategyHandler.apply(dom, args);
      });
    }
  }

  /**
   * 校验器执行：Fail-Fast 模式
   */
  start() {
    for (const validateStep of this.cache) {
      const msg = validateStep();
      if (msg) {
        return msg; // 发现首个错误立即中断
      }
    }
  }

  /**
   * 全量收集模式（可选）：收集所有错误项后统一展示
   */
  collectAll() {
    const errors = [];
    for (const validateStep of this.cache) {
      const msg = validateStep();
      if (msg) {
        errors.push(msg);
      }
    }
    return errors.length > 0 ? errors : null;
  }
}

五、完整业务落地与动态扩展演示

下面通过一个完整的注册表单展示如何在实际页面中完成配置装配，并演示如何零侵入扩展一条“自定义两次密码输入一致”业务策略。

1. 动态挂载新策略

当现有 strategies 仓库无法满足特定场景时，我们只需直接向 strategies 对象挂载新函数，无需重构或改动 Validator 类的任何逻辑：

// 无侵入扩充业务特化策略：两次输入比对
strategies.isSameAs = function (value, targetId, errorMsg) {
  const targetEl = document.getElementById(targetId);
  if (!targetEl || value !== targetEl.value) {
    return errorMsg;
  }
};

2. 客户端装配与事件响应

在页面代码中，我们将规则以配置声明的形式注册进验证器：

// 业务装配函数
function setupRegistrationValidation(form) {
  const validator = new AdvancedValidator();

  // 1. 用户名校验配置
  validator.add(form.username, [
    { strategy: 'isNonEmpty', errorMsg: '用户名不能为空' },
    { strategy: 'minLength:4', errorMsg: '用户名长度不能少于 4 位' }
  ]);

  // 2. 密码校验配置
  validator.add(form.password, [
    { strategy: 'isNonEmpty', errorMsg: '密码不能为空' },
    { strategy: 'minLength:8', errorMsg: '密码长度必须在 8 位及以上' }
  ]);

  // 3. 确认密码校验配置
  validator.add(form.confirmPassword, [
    { strategy: 'isNonEmpty', errorMsg: '请再次输入确认密码' },
    { strategy: 'isSameAs:pwdInput', errorMsg: '两次输入的密码不一致' }
  ]);

  // 4. 手机号码校验配置
  validator.add(form.mobile, [
    { strategy: 'isNonEmpty', errorMsg: '手机号不能为空' },
    { strategy: 'isMobile', errorMsg: '请输入有效的 11 位大陆手机号码' }
  ]);

  return validator;
}

// 绑定提交监听
const formElement = document.getElementById('userRegForm');
formElement.addEventListener('submit', (evt) => {
  evt.preventDefault();

  const validator = setupRegistrationValidation(formElement);
  const error = validator.start();

  if (error) {
    // 触发 UI 提示反馈
    renderErrorMessage(error);
    return;
  }

  // 校验全部通过，执行后续网络交互
  submitRegisterData(formElement);
});

六、边界考量与复杂场景扩展

虽然策略模式极大地优化了同步表单的解耦体验，但在实际前端架构选型时，仍需了解其边界与应对策略：

七、总结与最佳实践清单

通过策略模式重构表单验证，我们将原来散落在各处的条件分支梳理为结构规范的工程架构。在实际项目中落地该方案时，建议遵循以下五项核心准则：

• 保持策略函数无副作用：策略函数只对输入值做断言计算，不读写全局状态，不直接操作 DOM 样式。
• 参数与错误文案分离：利用冒号语法（如 minLength:8）或结构化参数对象，让校验阈值在配置期灵活注入，而非在策略内部硬编码。
• 闭包实现惰性求值：在 add() 阶段不立即提取 dom.value，仅将读取动作封装在闭包内，确保 start() 执行时始终获取用户提交那一刻的最新值。
• 区分错误阻断模式：对于长表单或用户体验敏感场景，支持由业务配置选择采用“发现首错即停（Fail-Fast）”还是“所有字段全量错误聚合（Collect-All）”。
• 开闭原则至上：当引入新校验规则时，以“只增不改”为目标，仅向策略仓库中注册新算法函数，核心调度器与其它既有表单逻辑应保持零改动。