答案是自定义规则提供灵活性、轻量性、可维护性和对复杂业务的适应能力，通过addRule注册函数与消息模板，结合配置对象实现字段与规则映射，并在验证失败时动态生成结构化错误信息以提升用户体验。
实现一个支持自定义规则的JavaScript表单验证库，核心在于构建一个灵活的规则注册机制和一套可扩展的验证执行流程。我们需要的不仅仅是简单的正则匹配，更是一种能让开发者像搭积木一样，自由定义和组合验证逻辑的能力。这套机制应该允许我们轻松地添加新的验证类型，并且能为不同的输入字段配置不同的验证组合，同时提供清晰的错误反馈。
解决方案
要实现这样一个库，我们通常会围绕一个核心的
Validator类或模块来构建。这个类需要具备以下关键能力：
-
规则注册机制 (
addRule
)：允许开发者定义新的验证规则。每个规则通常是一个函数，接收字段值和可能的参数，返回一个布尔值（true
表示通过，false
表示失败）。同时，为每个规则关联一个默认的错误消息模板。 -
验证执行器 (
validate
)：接收待验证的数据（例如表单字段的键值对）和一个验证配置对象。它会遍历配置，对每个字段应用相应的规则，并收集所有验证失败的信息。 - 错误信息管理：在验证失败时，能够清晰地指出哪个字段、哪个规则失败了，并提供友好的错误消息。
以下是一个简化的JavaScript实现骨架：
class CustomValidator {
constructor() {
this.rules = {}; // 存储所有注册的规则: { ruleName: { func: Function, message: String } }
this.errors = {}; // 存储验证失败的错误信息: { fieldName: [errorMessage1, errorMessage2] }
}
/**
* 注册一个新的验证规则。
* @param {string} name - 规则名称，如 'required', 'minLength', 'isEmail'。
* @param {function(value: any, ...args: any[]): boolean|Promise} func - 验证逻辑函数。
* @param {string} defaultMessage - 规则失败时的默认错误消息模板。
*/
addRule(name, func, defaultMessage = '字段不符合规则。') {
if (typeof func !== 'function') {
console.warn(`[CustomValidator] 规则 "${name}" 必须是一个函数。`);
return;
}
this.rules[name] = { func, message: defaultMessage };
}
/**
* 验证单个字段。
* @param {string} fieldName - 字段名称。
* @param {any} value - 字段的值。
* @param {object} fieldRulesConfig - 针对该字段的规则配置，如 { required: true, minLength: 5 }。
* @returns {Promise} - 包含该字段所有错误消息的数组，如果通过则返回空数组。
*/
async validateField(fieldName, value, fieldRulesConfig) {
let fieldErrors = [];
for (const ruleName in fieldRulesConfig) {
if (Object.prototype.hasOwnProperty.call(fieldRulesConfig, ruleName)) {
const ruleDefinition = this.rules[ruleName];
if (!ruleDefinition) {
console.warn(`[CustomValidator] 规则 "${ruleName}" 未注册。`);
continue;
}
const ruleFunc = ruleDefinition.func;
const ruleArgs = fieldRulesConfig[ruleName]; // 可能是 true，也可能是具体的参数值或对象
let isValid;
try {
// 尝试执行验证函数，支持异步验证
isValid = await Promise.resolve(
ruleArgs === true ? ruleFunc(value) : ruleFunc(value, ruleArgs)
);
} catch (e) {
console.error(`[CustomValidator] 规则 "${ruleName}" 执行出错:`, e);
isValid = false; // 出现异常也视为验证失败
}
if (!isValid) {
let errorMessage = ruleDefinition.message;
// 简单的消息模板替换
errorMessage = errorMessage
.replace('{field}', fieldName)
.replace('{value}', value);
// 如果ruleArgs是对象或数字，也可以替换，这里简化处理
if (typeof ruleArgs === 'number' || typeof ruleArgs === 'string') {
errorMessage = errorMessage.replace('{arg}', ruleArgs.toString());
} else if (typeof ruleArgs === 'object' && ruleArgs !== null) {
// 更复杂的参数替换，可能需要遍历ruleArgs的键值
for (const key in ruleArgs) {
if (Object.prototype.hasOwnProperty.call(ruleArgs, key)) {
errorMessage = errorMessage.replace(`{${key}}`, ruleArgs[key]);
}
}
}
fieldErrors.push(errorMessage);
}
}
}
return fieldErrors;
}
/**
* 验证整个表单数据。
* @param {object} formData - 表单数据，键值对形式。
* @param {object} config - 验证配置对象，如 { username: { required: true, minLength: 5 }, email: { isEmail: true } }。
* @returns {Promise} - 如果所有字段都通过验证则返回 true，否则返回 false。
*/
async validate(formData, config) {
this.errors = {}; // 重置错误信息
let hasOverallErrors = false;
const fieldValidationPromises = [];
for (const fieldName in config) {
if (Object.prototype.hasOwnProperty.call(config, fieldName)) {
const value = formData[fieldName];
const fieldRulesConfig = config[fieldName];
// 为每个字段创建一个验证Promise
fieldValidationPromises.push(
this.validateField(fieldName, value, fieldRulesConfig).then(fieldErrors => {
if (fieldErrors.length > 0) {
this.errors[fieldName] = fieldErrors;
hasOverallErrors = true;
}
})
);
}
}
await Promise.all(fieldValidationPromises); // 等待所有字段验证完成
return !hasOverallErrors;
}
}
// --- 示例用法 (这部分内容不会直接出现在输出中，仅作内部参考) ---
// const myValidator = new CustomValidator();
// myValidator.addRule('required', (val) => val != null && val !== '', '{field}是必填项。');
// myValidator.addRule('minLength', (val, len) => val.length >= len, '{field}至少需要{len}个字符。');
// myValidator.addRule('isEmail', (val) => /^\S+@\S+\.\S+$/.test(val), '{field}格式不正确。');
// myValidator.addRule('isNumber', (val) => !isNaN(parseFloat(val)) && isFinite(val), '{field}必须是数字。');
// myValidator.addRule('asyncCheckUsername', async (val) => {
// // 模拟一个异步请求
// await new Promise(resolve => setTimeout(resolve, 500));
// return val !== 'admin'; // 'admin' 用户名被占用
// }, '用户名"{value}"已被占用。');
// async function testValidation() {
// const data = {
// username: 'admin',
// email: 'invalid-email',
// password: '123',
// age: 'abc'
// };
// const validationConfig = {
// username: {
// required: true,
// minLength: 5,
// asyncCheckUsername: true
// },
// email: {
// required: true,
// isEmail: true
// },
// password: {
// required: true,
// minLength: 6
// },
// age: {
// isNumber: true
// }
// };
// const isValid = await myValidator.validate(data, validationConfig);
// console.log('Validation Result:', isValid);
// if (!isValid) {
// console.log('Errors:', myValidator.errors);
// }
// }
// testValidation(); 为什么我们需要自定义规则，而不是只用现成的库？
老实说，一开始我也觉得，市面上那么多成熟的表单验证库，比如VeeValidate、Formik配合Yup，或者Validator.js这种纯粹的验证工具，为什么还要自己去写一个呢？这不就是“重复造轮子”吗？但随着项目需求变得越来越复杂，我逐渐发现，自定义规则的必要性远超我的预期。
立即学习“Java免费学习笔记（深入）”；
首先，灵活性和控制力是核心。现有的库固然强大，但它们往往带着一套固定的设计哲学和API规范。当业务逻辑需要一些“奇奇怪怪”的验证，比如跨字段的复杂联动验证（“如果A字段选择了X，那么B字段就必须是Y”），或者需要与后端进行大量异步验证（“这个用户名是不是已经被注册了？”），现有库的抽象可能就显得有些捉襟见肘，或者实现起来异常别扭。自己构建，你可以完全按照项目的实际需求来定制，每个验证函数都为你所控，没有任何“黑盒”让你摸不着头脑。
其次，体积和性能也是一个考量。很多时候，我们可能只需要少数几个核心的验证功能，比如必填、长度、邮箱格式。引入一个功能大而全的库，可能会带来不必要的代码体积，尤其是在移动端或对加载速度有严格要求的场景下。自己写，可以按需引入，只包含你真正需要的部分，保持代码的轻量和高效。
再者，学习和理解。对我个人而言，自己动手实现一个功能，是对其原理最深刻的理解。当一个bug出现时，如果你用的是一个第三方库，你可能需要去翻阅它的源码或者文档，但如果你是作者，你对每一个细节都了然于胸，调试起来自然事半功倍。这种从零到一的实践，也极大地提升了解决问题的能力。
最后，特定场景的优化。比如你的项目可能高度依赖某个特定的UI框架，或者有自己一套独特的错误提示风格。自己实现的验证库可以更好地与这些项目特点融合，避免为了适应第三方库而进行不必要的妥协或复杂的适配层。所以，很多时候“造轮子”并非为了替代所有轮子，而是为了打造一个更适合自己特定车辆的专属轮子。
如何设计灵活的规则注册与应用机制？
设计一个灵活的规则注册与应用机制，是这个自定义验证库的灵魂。在我看来，它应该像乐高积木一样，既能让你快速搭建，也能让你自由组合。
1. 规则的本质：函数与消息
每个规则，本质上就是一个函数。这个函数接收要验证的值，以及可能的一些额外参数（比如
minLength规则需要知道最小长度是多少），然后返回
true或
false。同时，为了友好的用户体验，每个规则都应该有一个默认的错误消息模板。
// 示例：定义一个规则
myValidator.addRule('minLength', (value, min) => value.length >= min, '{field}至少需要{min}个字符。');这里
{field}和{min}就是消息模板中的占位符，方便我们在运行时动态替换。
2. 注册接口 (addRule
)
我们需要一个清晰的API来注册这些规则。
addRule(name, func, defaultMessage)就很好地满足了这一点。
name是规则的唯一标识符，
func是验证逻辑，
defaultMessage是当验证失败时显示的默认消息。这个接口让库的核心逻辑与具体的验证规则解耦，开发者可以不断地扩展规则集，而无需修改核心验证器。
3. 配置对象：字段与规则的映射
在验证整个表单时，我们不能硬编码哪个字段用哪个规则。一个配置对象是最佳选择，它清晰地定义了每个字段需要应用哪些规则，以及这些规则的参数。
const validationConfig = {
username: {
required: true, // 必填，没有额外参数
minLength: 5, // 最小长度，参数是5
// asyncCheckUsername: true // 异步规则，参数是true表示启用
},
email: {
required: true,
isEmail: true
}
};这种结构直观且易于理解。
true表示启用该规则，如果规则需要参数，直接将参数值作为属性值。
4. 参数传递与异步考量
验证函数如何接收参数？当我们在
addRule时定义了
func(value, ...args)，那么在
validateField中，我们就可以根据
fieldRulesConfig[ruleName]的值来决定如何调用规则函数。如果
fieldRulesConfig[ruleName]是
true，就只传
value；如果是其他值（如
5或一个对象），就将这个值作为额外参数传递。
对于异步验证，比如前面提到的
asyncCheckUsername，验证函数本身可以是一个
async函数，返回一个
Promise。在
validateField中，我们使用
await Promise.resolve(ruleFunc(...))来确保无论是同步还是异步规则，都能被正确地等待和处理。这是在设计时一个很重要的发散点，因为现代Web应用中，异步验证场景越来越多。
通过这样的设计，我们不仅能注册简单的同步规则，也能优雅地处理复杂的异步验证，而且配置方式保持了一致性，我觉得这才是真正的灵活。
错误信息如何友好地呈现给用户？
验证的最终目的，不是为了证明用户错了，而是为了引导用户把信息填写正确。所以，错误信息的友好呈现，其重要性不亚于验证逻辑本身。一个再强大的验证库，如果错误提示一塌糊涂，那用户体验也会大打折扣。
1. 结构化的错误收集
当
validate方法执行完毕后，它应该返回一个清晰的错误对象，而不是一个简单的布尔值。比如，
this.errors这个对象，它以字段名为键，值为一个包含所有错误消息的数组。
// 示例错误对象
{
username: ["用户名是必填项。", "用户名至少需要5个字符。"],
email: ["邮箱格式不正确。"]
}这种结构化数据，使得前端UI层可以非常方便地遍历并展示错误，比如在每个输入框下方显示对应的错误消息，或者在表单顶部统一显示一个错误汇总。
2. 消息模板与动态替换
我们之前在
addRule中为每个规则定义了
defaultMessage，其中包含了
{field}、{value}、{arg}等占位符。在validateField中，当一个规则验证失败时，我们就可以根据当前的字段名、字段值和规则参数，动态地替换这些占位符，生成具体的、有上下文的错误消息。
例如，
{field}至少需要{min}个字符。在验证username字段，最小长度为
5时，会变成
用户名至少需要5个字符。。这种动态生成的方式，避免了硬编码大量错误消息，提升了可维护性。
3. 国际化（i18n）的考虑
如果项目需要支持多语言，那么错误消息的国际化是不可避免的。一种简单的做法是，在
addRule时，
defaultMessage可以是一个对象，键是语言代码（如
en,
zh），值是对应语言的消息模板。或者，在初始化
Validator实例时，传入
