企业级数据校验需兼顾准确性、可维护性、可扩展性与业务语义,应统一使用封装判定函数区分基础/引用类型,分三层定义规则,返回结构化错误并集成成熟库但避免副作用。

明确基础类型与引用类型的判定标准
JavaScript 的类型判断容易踩坑(比如 null 被 typeof 误判为 "object"),应统一使用封装后的判定函数:
-
基础类型:用
typeof x === 'string' || typeof x === 'number' || ...显式枚举,不依赖typeof null -
引用类型:优先用
Object.prototype.toString.call(x)获取精确标签,例如[object Date]、[object Map] -
特殊值:单独处理
null(x === null)、undefined(x === undefined或void 0)、NaN(必须用Number.isNaN(x))
按业务场景分层定义校验规则
单纯“是不是字符串”没意义,关键看“是否为合法手机号”“是否为有效 ISO 日期字符串”。建议分三层组织:
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
原始类型断言:如
isString(x)、isNumber(x)—— 仅做类型兜底 -
格式化校验:如
isEmail(x)、isIdCard(x)、isISO8601(x)—— 基于正则或算法(如身份证校验码) -
业务约束校验:如
isWithinAgeRange(x, 18, 80)、isPositiveInteger(x)、isInEnum(x, ['draft', 'published'])—— 绑定具体业务逻辑
统一错误反馈与上下文管理
校验不是布尔返回就结束,企业级系统需支持:
- 失败时返回结构化错误对象:
{ valid: false, field: 'phone', code: 'INVALID_FORMAT', message: '手机号格式不正确' } - 支持多语言提示:错误消息由后端返回或前端 i18n key 映射,避免硬编码中文
- 批量校验时保留所有字段结果,而非遇到第一个失败就中断(便于表单一次性展示全部错误)
- 对异步校验(如用户名是否已存在)单独建模,避免与同步校验混用同一接口
集成 validator.js 等成熟方案但不盲从
validator.js 提供了 200+ 高质量验证函数,适合直接复用邮箱、URL、信用卡等通用规则,但要注意:
- 禁用其内置的
trim、toLowerCase等副作用操作,改由业务层显式控制数据预处理 - 不直接在表单提交逻辑里调用
isEmail(input.value),而是封装成validateField('email', value),统一注入配置(如是否必填、是否忽略空值) - 对中文手机号、大陆身份证、银行联行号等强地域规则,仍需自研校验函数,不可依赖泛化库
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










