不能完全限制，min/max仅在提交或调用checkValidity()时触发原生校验，不阻止键盘输入、粘贴或脚本赋值；需结合input事件监听与setRangeText()或value截断修正才能实现实时约束。
number input 的 min/max 属性是否真能限制用户输入？
不能完全限制。用户仍可通过键盘直接输入超出范围的值，min 和 max 仅触发浏览器原生校验（提交时或调用 checkValidity() 时才报错），且不阻止粘贴、脚本赋值等行为。真正生效的约束需结合事件监听与手动修正。
oninput + setRangeText 实现实时范围拦截
在用户输入过程中就干预，比等失焦再修正体验更自然。关键不是阻止输入，而是「自动修正」为合法值。推荐用 input 事件配合 setRangeText() 或直接重设 value：
<input type="number" id="stepper" min="0" max="100" step="5">
setRangeText() 适合保留光标位置，但兼容性略差（IE 不支持）；更稳妥的做法是读取当前值 → 截断 → 写回，并手动恢复光标（可选）：
- 监听
input事件，而非change（后者只在失焦时触发） - 用
parseFloat(event.target.value)解析，避免空字符串或非法字符导致NaN - 用
Math.min(Math.max(value, min), max)截断，再转回字符串写入value - 若需保留小数位（如
step="0.1"），注意用toFixed()或Number().toPrecision()控制精度，否则可能产生浮点误差
step 属性对键盘箭头和点击按钮的实际影响
step 不仅控制点击上下箭头的增量，还影响浏览器对“合法值”的判断（例如 step="5" 时，输入 12 不会立即报错，但提交时校验失败）。但注意：
- 若未设
step，默认为1；设为any则禁用步进校验（但仍受min/max约束） - 键盘按上下箭头时，浏览器内部按
step计算新值，但若当前值非min + n × step的形式，首次点击可能跳到最近合法值，行为不易预测 - 移动端软键盘通常不显示箭头，
step对其无实际作用
需要兼容旧浏览器或自定义 UI 时，该放弃原生 number input 吗？
应该。当项目需支持 IE11、或要求精确控制步进动画、或需在输入框内显示单位/图标时，原生 input[type="number"] 的样式与行为不可靠（如 Chrome 会强制显示上下箭头，Safari 在 iOS 上常忽略 min/max）。此时建议：
- 用
input[type="text"]+ 正则限制数字输入（/^-?\d*\.?\d*$/），再通过keydown过滤非数字键 - 封装一个带
increment()/decrement()方法的类，统一处理min/max/step逻辑 - 避免依赖
event.data（Safari 不支持），改用input.valueBeforeInput（实验性）或直接比对前后值
原生控件省事，但边界情况太多；一旦出现用户输入异常值后无法提交、或某次更新后步进失效，问题往往出在没覆盖粘贴、拖拽、脚本赋值这些路径。
