data-rule-id 是最轻量可靠的元数据载体，通过显式绑定业务规则ID与HTML字段，解决原生属性无法表达语义的问题，并需在初始化时扫描补全缺失项。
原生 HTML 表单属性（required、pattern、minlength 等）本身不携带结构化元数据，直接用于大规模校验时无法自动提取业务语义——比如你没法从 pattern="[0-9]{11}" 推出这是“中国大陆手机号”，也没法知道 minlength="8" 对应的是“密码最小长度”还是“用户名最小长度”。所谓“元数据映射”，本质是把 HTML 属性值和业务规则描述做显式绑定，而不是靠猜。
为什么不能直接用 pattern 值当校验规则 ID？
浏览器只把 pattern 当正则字符串执行，不解析其业务含义。同一正则可能在不同字段复用（如两个 pattern="[a-z0-9_]{3,20}" 字段，一个是用户名，一个是设备 ID），但错误提示、日志埋点、后端校验同步都需要区分上下文。
常见错误现象：
• 把 pattern 值硬编码进 JS 提示文案，导致改正则就得同步改文案
• 用正则字符串做 API 错误码映射，结果后端返回 "invalid_phone"，前端却找不到对应字段
• 导出表单规则给测试或后端时，只能人工整理 HTML 源码，漏项率高
data-rule-id 是最轻量可靠的元数据载体
HTML 允许自定义 data- 属性，且所有现代浏览器原生支持读取，不干扰渲染也不触发验证逻辑。它比 class 名更语义清晰，比注释更易机器提取。
实操建议：
• 每个需校验的字段显式声明 data-rule-id，值为小写蛇形命名的业务标识，如 data-rule-id="user_mobile"
• 同一业务规则可复用多个字段，例如注册页和修改页的手机号都用 data-rule-id="user_mobile"
• 配套提供一份 JSON 规则表，例如：
{ "user_mobile": { "pattern": "^1[3-9]\d{9}$", "message": "请输入正确的中国大陆手机号", "level": "error" } }• JS 校验时优先读
data-rule-id，再查规则表，避免硬编码正则或文案
如何让 required 和 type 也参与元数据体系？
required 本身是布尔值，type 是有限枚举，它们的语义太弱，必须组合使用才能表达完整约束。单独依赖它们做元数据映射会丢失关键信息。
实操建议：
• 不把 required 当独立规则，而是作为 data-rule-id 对应规则的子属性（如规则表里 "required": true）
• type="email" 仅保留语义提示作用，实际格式校验仍走 data-rule-id 查表得到的 pattern，因为浏览器原生校验太宽松
• 对 type="number" 字段，必须额外用 data-rule-id 显式绑定数值范围规则（如 data-rule-id="age_range"），因为 min/max 属性无法被 JS 自动识别为业务约束
立即学习“前端免费学习笔记（深入）”；
大规模场景下容易忽略的兼容性断层
元数据映射方案在开发期很干净，但上线后常因三类问题崩塌：
• 动态插入的字段（如 JS 添加的行项目）忘了加 data-rule-id，导致校验逻辑跳过该字段
• 第三方组件库（如 Vue 封装的 <input>）内部没透传 data-rule-id 到真实 DOM 节点
• 构建工具（如 Webpack + HTML minifier）默认移除空的 data- 属性，必须配置保留 data-rule-id
真正落地时，得在表单初始化函数里加一道扫描：遍历所有 input、select、textarea，检查是否缺失 data-rule-id，缺失则报错或 fallback 到默认规则 ID（如 "fallback_field"）
