min/max仅参与提交校验，不拦截输入；须用javascript实时截断+服务端二次验证，且type必须为number，否则属性被忽略。
min 和 max 属性本身不拦截输入，只参与提交校验；真正限制范围必须靠 JavaScript 主动截断 + 服务端二次验证。
为什么 min/max 常常“没反应”
浏览器只对 type="number" 解析这两个属性，type="text" 或缺省 type 时完全忽略。用户粘贴、键盘输入超限值（如 999 却设了 max="100"）不会被实时阻止——只有点击提交或调用 form.reportValidity() 才触发提示。iOS Safari 甚至允许手动输入超限值，仅在失焦或提交时才报 ValidityState.rangeOverflow 错误。
用 input 事件实时修正值
监听 input（不是 change）才能响应每一次按键、粘贴、拖拽：
- 用
parseFloat(el.value)取值，比el.valueAsNumber更容错（后者遇到"12abc"或末尾小数点直接返回NaN） - 显式转成数字后与
parseFloat(el.min)、parseFloat(el.max)比较 - 超限时直接赋值为边界：
el.value = el.min或el.value = el.max - 注意空输入：若
parseFloat("")得NaN，应跳过校验，避免清空后又被重置
示例代码：
const el = document.querySelector('input[type="number"]');
el.addEventListener('input', () => {
const val = parseFloat(el.value);
if (!isNaN(val)) {
const min = parseFloat(el.min) || -Infinity;
const max = parseFloat(el.max) || Infinity;
if (val max) el.value = String(max);
}
});
移动端和兼容性避坑要点
type="number" 在 Android 和 iOS 上行为差异大：
- iOS Safari 不显示增减按钮，且对
step支持弱；设了step="0.5"仍可能输入0.33 - 某些安卓 WebView 对
max超过1000000的输入框会崩溃（Chromium 旧版已知 bug） - 更稳妥的方案是改用
type="text" inputmode="decimal"+ JS 全面接管：过滤非数字字符、控制范围、对齐步长 -
step不只是“微调单位”，它影响合法值序列：若min="1" step="2"，合法值是1,3,5...，输入4应修正为5（需额外逻辑）
服务端必须重复校验
前端所有限制都可被绕过：curl 直接 POST、禁用 JS、修改 DOM 属性……后端收到的永远是原始字符串。必须做三件事：
- 类型转换：用
float()或int()（Python），或Number()（Node.js），并检查是否为有效数字 - 范围判断：显式比较是否在
min～max之间，别依赖框架中间件的默认行为 - 数据库加约束：比如 PostgreSQL 的
CHECK (score BETWEEN 0 AND 100)，防数据污染
最易被忽略的一点：很多人以为设了 min="0" max="100" 就万事大吉，却忘了 value 是字符串，parseInt("100px") 仍得 100——后端必须先清洗再转换，不能裸调解析函数。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
