type="number" 配合 min/max/step 是最可靠方式，浏览器原生拦截非法输入、触发校验、弹数字键盘；pattern + text 仅提交时校验，中间脏数据多，移动端兼容差。
直接用 type="number" 配合 min/max/step 是最可靠的方式，浏览器原生拦截非法输入、触发校验、弹数字键盘——别先写 JS 校验逻辑，那是在补救本不该出现的问题。
type="number" 为什么比 pattern + text 更稳
浏览器对 type="number" 的处理是「输入层拦截」：用户按字母键、粘贴带单位的字符串（如 "12px"）、输入多个小数点，值根本不会进 input.value；而 type="text" + pattern 只在提交时校验，中间过程全是脏数据，光标跳动、失焦清空、移动端兼容性差等问题频发。
-
min和max是数值比较，不是字符串匹配，min="-5"能正确拒绝"-10"，但正则^-?[0-5]$会误判负数 -
step="1"强制整数，step="0.01"支持两位小数，比手写正则^-?\d+(\.\d{1,2})?$少踩边界坑 - 移动端自动调起数字键盘（含小数点和负号键），
pattern对键盘类型无控制力
pattern 属性只适合 text 类型的兜底场景
当你必须用 type="text"（比如要支持千分位逗号、或后端要求提交字符串格式），才考虑 pattern。此时正则必须锚定首尾，且注意字符集陷阱：
- 错误写法：
pattern="[0-9.]+"——[0-9.]是字符集，会匹配"..99"或"...." - 正确写法：
pattern="^-?\d+(\.\d+)?$"，但需配合title="请输入合法数字"，否则 Chrome 不显示提示 - 如果允许千分位（如
"1,234.56"），pattern 基本失效，得靠 JS 在input事件里用replace(/[^0-9.,]/g, '')过滤，再用parseFloat()校验有效性
JavaScript 校验时 parseFloat() 和 isNaN() 的坑
别直接用 isNaN(input.value) 判断——空字符串、空格、" " 都返回 false（因为被转成 0）；parseFloat() 遇到开头非数字就返回 NaN，但 "123abc" 会返回 123，属于半截合法。
立即学习“前端免费学习笔记（深入）”；
- 安全做法：
const n = parseFloat(input.value); if (isNaN(n) || !isFinite(n)) { /* 非法 */ } - 更严一点：用
Number(input.value)替代parseFloat()，它对尾部乱码更敏感（Number("123abc") === NaN） - 如果业务要求「必须完整匹配数字字符串」，用正则
^-?\d*\.?\d+$先测试input.value是否纯数字格式，再转数值
提交前务必用 checkValidity() 主动触发原生校验
即使用了 type="number"，也不代表表单一定能通过校验——用户可能手动清空字段、或绕过 UI 直接改 DOM。提交前必须显式调用：
form.addEventListener('submit', e => {
if (!form.checkValidity()) {
e.preventDefault();
// 浏览器已高亮错误字段并显示默认提示
}
});
这个方法会触发所有原生约束（required、min/max、pattern 等），比自己遍历每个字段写 if 判断更准，也兼容自定义 setCustomValidity() 的逻辑。
真正容易被忽略的是：原生校验只管格式与范围，不管业务语义。比如「年龄不能小于出生年份推算值」「折扣率不能超过 100%」——这些必须用 JS 在 submit 里单独判断，且错误信息要用 input.setCustomValidity("xxx") 注入，否则 checkValidity() 不会把它算作失败项。
