min/max仅提供语义约束和提交校验，需JavaScript实时拦截+服务端重复验证才可靠；仅number、range、date类input类型原生支持，text等无效；常见失效因手动输入越界值、动态赋值不更新UI、非法格式或缺失step；JS需监听input事件解析归正、设自定义提示并保留原生属性；服务端必须独立校验，不可信任前端任何限制。
仅靠 min 和 max 属性无法真正阻止用户输入越界值，它们只提供语义约束和提交时校验，必须配合 JavaScript 实时拦截 + 服务端重复验证才可靠。
哪些 input type 支持 min 和 max
只有明确具备数值或时间语义的类型才原生生效：
-
number、range：值必须是合法数字字符串，如"0"、"10.5"；"10.00"在旧版 Chrome 中小数位可能被忽略 -
date、datetime-local、month、week、time：日期类必须严格为"YYYY-MM-DD"格式，"2024-3-1"或"2024/03/01"会静默失效 -
text、email、tel、color、file等加了也无效——浏览器完全忽略
min 和 max 常见失效场景
不是属性写错了，而是使用方式触发了浏览器的“宽容”逻辑：
- 手动输入或粘贴越界值（如
max="100"但用户粘贴"999"），浏览器不拦截，只在提交时标记:invalid - 动态赋值用
input.min = "2024-01-01"，Safari 可能不更新 UI；应统一用input.setAttribute('min', '2024-01-01') -
min或max值为null、undefined或非法格式（如"2024-13-01"）时，属性静默失效，等同于未设置 - 未配
step时，type="number"允许任意精度小数；设max="1"仍可输"0.9999999"，需显式step="0.01"才控制粒度
如何用 JavaScript 补足原生限制的缺口
监听 input 事件实时归正，比等 change 或提交再处理更及时：
立即学习“前端免费学习笔记（深入）”；
- 用
parseFloat(el.value)解析，比Number()更容错（能处理"007"、"1.5"） - 先判断
isNaN(val)，避免空值或"12a"类字符串导致逻辑跳过 - 对
step有要求的场景，需手动取整：Math.round((val - base) / step) * step + base - 调用
el.setCustomValidity()替换默认提示，例如el.setCustomValidity('不能超过' + el.max) - 务必保留原生
min/max属性——作为 JS 失效时的降级兜底
服务端永远不能信任前端的 min/max
用户禁用 JS、改 DOM、curl 直接 POST，都能绕过所有前端限制。你看到的 min="1" max="120" 对后端来说只是建议，不是契约。真正起作用的只有服务端解析后再次校验：比如用 parseFloat(req.body.age) 后再比对范围，且必须拒绝非数字字符串。最容易被忽略的是——连 input.valueAsNumber 返回 NaN 这种前端已发现的错误，后端若不做同等解析，照样入库脏数据。
