假设一个报名表把邮政编码设成数字输入，开发者觉得这样可以减少错误。可这个字段承担的是标识地址区域的任务，并不需要参与加减乘除。把它当成数值，反而可能丢掉用户需要保留的表示方式。
W3C WAI 的表单校验教程提醒，要考虑电话等输入的不同格式；邮政编码也不适合简单当作数字。它还区分 required 与 aria-required：后者传达必填语义，本身不负责执行校验。浏览器中的检查也不能代替服务端验证。
我建议在写正则前给字段做一个小分类：数量、标识符、自由文本、日期或受控选项。数量需要讨论单位、精度和范围；标识符需要讨论允许字符、长度及前导零；自由文本需要讨论长度和业务要求。分类不是数据模型的终点，却能避免拿同一套“只许数字”规则处理所有东西。
一个假设性的客户编号 0012，可以和编号 12 是不同记录。即使目前后台只产生数字字符，也不代表它是数值。如果业务允许前导零，前端、接口、数据库与导出应一起保留字符串语义。这里没有进行任何具体产品的兼容测试，编号仅用于说明。
校验还可以分成三步：保留原始输入；仅做已明确允许的规范化；再判断业务是否接受。例如是否允许删除电话号码中的空格，必须由支持范围决定，而不是遇到不认识的字符就无声删除。规范化后的值最好能让用户看见，避免输入正确却被改成另一个含义。
最小测试矩阵包括空值、边界长度、前导零、复制粘贴带空格、合法分隔符，以及绕过页面直接提交接口。错误提示应指向可修复的条件，比如“客户编号需要 4 位字符”，而不是把所有失败写成“格式错误”。
过严校验会挡住真实输入，过松校验会把问题推给后续流程。可以先明确产品支持的地区与格式，再对不支持的输入给出具体原因；不要用未经验证的万能正则制造一种“全世界都支持”的承诺。
资料：W3C WAI 表单校验教程；持续维护页面，未取得页面更新时间。查阅日期：2026-11-05（Asia/Shanghai）。
