边界值校验必须结合input的min/max/step属性与JavaScript的valueAsNumber、setCustomValidity形成闭环，且需前后端双重校验。
边界值校验必须在 input 的 min/max 和 step 属性上做文章
浏览器原生表单校验对边界值最直接的支持，就是 input 元素的 min、max 和 step 属性。它们不是装饰，而是触发 validity.rangeUnderflow、validity.rangeOverflow 和 validity.stepMismatch 的关键开关。
常见错误是只写 type="number" 就以为能拦住非法值——其实不设 min/max，用户仍可输入任意数字（包括负数、超大数），且不会触发校验失败状态。
-
min和max必须是字符串形式的数字（如"0"、"100"），不能是数字类型（0会被忽略） -
step默认为"1"；若允许小数，必须显式声明（如step="0.01"），否则1.5会被判为stepMismatch - 日期类输入（
type="date"）同样支持min/max，值格式必须为"YYYY-MM-DD"（如min="2024-01-01"）
JavaScript 手动校验时，别用 parseInt 或 parseFloat 做边界比对
用户输入可能含空格、前导零、科学计数法甚至非数字字符（如 " 42 "、"007"、"1e2"）。直接用 parseInt(input.value) 或 parseFloat 转换再比较，会掩盖格式问题，且无法复现原生校验逻辑。
正确做法是复用浏览器解析结果：读取 input.valueAsNumber（对 type="number"）或 input.valueAsDate（对 type="date"），它已按标准规则处理了格式，并在非法时返回 NaN 或 null。
立即学习“前端免费学习笔记（深入）”；
- 检查
input.valueAsNumber === NaN不可靠，应使用isNaN(input.valueAsNumber) - 当
valueAsNumber有效但超出min/max，需手动设置setCustomValidity并调用reportValidity() - 避免在
input事件里频繁调用checkValidity()，它会触发样式重绘；建议改用blur或提交时集中校验
pattern 对数值边界无效，别把它和 min/max 混用
pattern 是正则匹配，只管字符串形态，不管数值大小。比如 pattern="[0-9]{1,3}" 看似限制 0–999，但实际会放过 "000"、"999"，也放过 "5000"（因为只匹配开头三位）；更糟的是，它会让 type="number" 失去原生增减按钮和软键盘优化。
唯一适合 pattern 的场景是「格式约束强于数值约束」的情况，例如要求手机号必须是 11 位数字、密码必须含大小写字母和数字——这些跟边界值无关。
- 数值型字段优先用
min/max/step，这是语义正确且无障碍友好的方式 - 若后端要求字符串格式（如固定长度编号），应在提交前用 JS 格式化，而非靠
pattern强制 -
pattern错误提示不可定制，而setCustomValidity可以提供精准文案
移动端软键盘适配差，type="number" 的边界控制常被绕过
Android Chrome 和部分 iOS 版本中，type="number" 的软键盘仍允许输入字母、符号甚至粘贴非法内容，min/max 属性此时形同虚设——用户能输，也能点提交，直到 JS 校验或后端拦截。
这不是 bug，是规范允许的行为：HTML 表单校验是“增强”而非“强制”。所以真实项目中，边界校验必须前后端一致，前端仅作体验优化。
- 不要依赖
input[type=number]防止非法输入，它只是提示浏览器展示数字键盘 - 对关键字段（如金额、年龄），在
blur或submit时用valueAsNumber+ 显式范围判断 - 服务端必须重复校验，且不能信任
$_POST或req.body中的原始字符串值
valueAsNumber、setCustomValidity 形成闭环，以及是否接受「前端永远可被绕过」这个事实。 
