type="number"的min/max仅提交时校验数值，不阻止非法字符输入；pattern对其无效，需改用type="text"并配合正则；date/datetime-local的min/max需ISO格式；前后端均须校验，后端不可信任前端限制。
type="number" 的 min/max 属性只校验数值，不阻止非法字符输入
浏览器对 type="number" 的原生校验仅在提交时检查最终解析出的数值是否落在 min/max 范围内，但不会拦截用户输入字母、多个小数点、连字符等无效字符。例如：<input type="number" min="0" max="100"> 允许用户输入 "12.34.5" 或 "abc"，直到提交时才报错，且错误提示模糊（如“请输入有效数字”）。
这容易让用户困惑，尤其在移动端软键盘未自动切换为数字键盘时。解决方法是：配合 step 控制精度（如 step="1" 禁用小数），并用 JavaScript 监听 input 事件做实时清理：
- 监听
input事件，用正则/^-?\d*\.?\d*$/过滤非数字字符（保留负号和小数点） - 输入后立即
parseFloat()并判断是否在范围内，超界则重置为边界值或清空 - 避免直接修改
value导致光标跳到末尾，可使用setSelectionRange保持光标位置
pattern 属性无法用于 type="number"，必须改用 type="text"
pattern 属性在 type="number" 上会被浏览器忽略——这是 HTML 规范明确规定的限制。如果你需要精确匹配如“0–23之间的整数”或“带固定小数位的金额”，必须将类型改为 type="text"，再用 pattern 配合正则实现。
例如，限制小时值 0–23（含前导零）：
立即学习“前端免费学习笔记（深入）”；
<input type="text" pattern="^(?:[0-9]|1[0-9]|2[0-3])$" title="请输入0–23之间的整数">
注意点：
- 正则中不能写
[0-23]，那是字符集，不是数值范围；应拆解为[0-9]、1[0-9]、2[0-3] - 必须加
^和$锚定首尾，否则"123"会意外匹配"12"部分 -
title是必填项，否则验证失败时不显示提示
min/max 对 date、datetime-local 等类型生效，但需注意格式兼容性
min 和 max 在 type="date"、type="datetime-local" 中能正确限制可选日期范围，但值必须是标准 ISO 格式（YYYY-MM-DD 或 YYYY-MM-DDTHH:MM）。常见坑：
- JavaScript 生成的
new Date().toISOString().split('T')[0]可用，但toLocaleDateString()输出的本地格式（如 “2026/9/6”）会导致属性失效 - 移动端 Safari 对
datetime-local支持差，建议降级为两个独立字段（date + time）或用第三方 picker -
min值设为今天，应动态生成并写入 HTML，而非依赖 JS 后置设置（否则初始加载时校验不触发）
服务器端必须重复校验，前端范围限制纯属体验优化
所有前端的 min、max、pattern 都可被绕过：禁用 JS、手动修改 DOM、curl 提交任意值。因此后端收到数据后，必须重新解析并校验数值范围与格式。
关键动作：
- 先做类型转换（如
parseInt()、parseFloat()），捕获 NaN 或溢出 - 再比对业务逻辑要求的上下界，而非仅依赖前端传来的原始字符串
- 对
date类型，用服务端日期库（如 Luxon、date-fns）解析并校验有效性，防止“2026-02-30”这类非法日期通过
最易被忽略的是：前端用 pattern 限制了“0–23”，后端若只做 int(value) >= 0 and ，仍可能因类型转换失败或截断导致越界——比如用户提交 <code>"23.9"，前端没拦住，后端 int("23.9") 得到 23，看似合法，实则丢失精度，需按业务决定是拒绝还是四舍五入。
