step="0.1"输入2.05报stepmismatch，因浏览器提交前校验要求(value−min)%step===0，而(2.05−min)/0.1非整数；该属性仅约束微调、键盘增减及提交校验，不实时拦截输入。
step="0.1" 输入 2.05 为什么会报 stepMismatch？
浏览器在表单提交或调用 checkValidity() 时，会执行原生校验：只要 value 不满足 (value - min) % step === 0（且在 min/max 范围内），就触发 stepMismatch。2.05 对 step="0.1" 来说，等价于 (2.05 - min) / 0.1 不是整数——哪怕你手动敲进去、粘贴进去，它都合法存在于输入框中，直到校验那一刻才失败。
常见错误现象：
- 用户输入 2.05 后点提交，弹出“值必须为 0.1 的倍数”，但控制台没报错，
input.validity.stepMismatch为true - 用键盘上下键或微调箭头输值，永远跳不到 2.05，只能停在 2.0 或 2.1 —— 这不是拦截，是步进逻辑本身不生成该值
-
input.value = "2.05"在 JS 中赋值后，checkValidity()立即返回false，但输入框内容不变
为什么 step 属性不实时拦截非法输入？
step 不是输入过滤器，它只约束三件事：微调按钮行为、键盘 ↑/↓ 增减、以及提交前的校验。所有 input 事件（包括 oninput、onchange）里，浏览器都允许中间态非法值存在。
实操建议：
- 不要指望
step防止用户输 2.05；它只保证“你能点出来的值”和“能提交的值”是合法的 - 若需实时规整（比如输 2.05 自动变成 2.1），必须监听
blur或input事件，用 JS 手动计算最近合法值：Math.round((value - min) / step) * step + min - 注意浮点精度：直接用
0.1计算可能得0.30000000000000004，建议先parseFloat(value).toFixed(1)再参与运算
step="0.1" 在 Safari 和旧版 Chrome 中为何表现异常？
根本原因是 0.1 在 IEEE 754 双精度下无法精确表示，导致 (value - min) % step 计算结果漂移。部分浏览器（如 Safari ≤15.4）甚至会把 step="0.1" 静默转成 step="1"，让小数输入直接失效。
规避方案：
- 金额类场景一律用整数单位：设
min="100"、max="99999"、step="1"，对应“分”，显示时除以 100 - 若必须用小数，统一写满位数：
min="0.00"、max="10.00"、step="0.01"，减少解析歧义 - 避免
step="0.1"搭配min="1"这种组合——1.1看似合法，但某些引擎计算(1.1 - 1) % 0.1得0.09999999999999998，判定为不合法
step="any" 真的能绕过步长限制吗？
step="any" 只禁用三件事：微调箭头步进、stepUp()/stepDown() 的步长依据、以及 stepMismatch 校验。它不解决浮点精度问题，也不让 valueAsNumber 更精确。
容易踩的坑：
-
step="any"下点 ↑，value="1.5"会变成"2.5"（±1 整数增减），不是你想要的 ±0.1 - Safari ≤15.4 完全忽略
step="any"，仍按step="1"处理，小数输入可能被清空 - 粘贴
"0.1"后读取valueAsNumber，仍是0.10000000000000001，这不是step的锅，而是 JS 数值模型本身 - 表单提交时，
FormData会调用valueAsNumber再转字符串，原始输入的"0.10000000000000001"可能被替换成失真后的"0.1"，不可逆
真正需要强控精度的场景，step 从来不是主力——它只是轻量提示层，兜底必须靠 JS 格式化 + 后端校验。
