step属性不解决浮点精度丢失问题，因其底层依赖IEEE 754浮点数表示，0.1等十进制小数在内存中本就是近似值；真正规避方案是用整数单位、统一小数位数、字符串处理或动态重置value。
step 属性本身**不解决精度丢失问题**，它只定义合法值的数学序列；所有你以为的“0.3 变成 0.30000000000000004”，根源是 IEEE 754 浮点数无法精确表示 0.1、0.01 等十进制小数——浏览器和 JS 引擎都逃不开这个限制。
为什么 step="0.1" 点两次 ↑ 得到 0.30000000000000004
这不是 step 的 bug，也不是浏览器故意搞事。当你写 step="0.1"，浏览器内部仍用 JS 的 Number 类型解析这个字符串，而 0.1 在内存里实际存的是 ≈0.10000000000000000555。后续所有加法（包括 stepUp()）都在这个近似值上运算。
-
input.stepUp(1)不比parseFloat(val) + 0.1更准，它只是封装了同一套浮点逻辑 - 旧版 Chrome 甚至会把
step="0.1"静默降级为step="1"，你根本没在用小数步进 - 用户粘贴
"0.15"或拖动滑块时，step校验可能被绕过，valueAsNumber 一读就是带误差的值
真正能规避精度问题的实操路径
别指望靠改 step 值来“修复”浮点误差。有效做法是绕开浮点数参与计算的环节：
- 金额类场景一律用整数单位：
min="199"、step="1"、value="199"表示 1.99 元，后端再除以 100 - 必须用小数时，统一小数位数：
min="0.00"、max="10.00"、step="0.01"，避免混用"0"和"0.00" - 需要高精度输入（如科学参数），直接换
type="text"+inputmode="decimal"+ 正则过滤，全程保留字符串，交由decimal.js或后端解析 - 动态改
step后，必须立刻重置value：input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2)，否则控件卡死
step="any" 到底能不能用
step="any" 不是“关闭精度校验”，而是**退化为 ±1 整数步进**：上下箭头按 1 增减，stepUp() 也按 1 跳，且不再触发 validity.stepMismatch。但它完全不改变 valueAsNumber 的浮点解析行为，也不阻止 0.1 + 0.2 === 0.30000000000000004。
立即学习“前端免费学习笔记（深入）”；
- Safari ≤15.4 直接忽略
step="any"，仍按step="1"校验，小数输入可能被清空 - 提交时
FormData.get("x")拿到的是原始字符串，但如果你紧接着调用Number()或参与运算，误差立刻出现 - 它唯一靠谱的用途：保留原生 spinner 按钮，同时允许用户自由输入任意字符串（比如
"1e-10"），但后续所有精度保障得你自己兜底
最常被忽略的一点：哪怕你把 min、max、step 全设对了，只要初始 value 不满足 value === min + n × step（n 为整数），浏览器就会静默修正——你点 ↑ 没反应、拖滑块跳变、checkValidity() 返回 false，问题就出在这儿，不是 JS 写错了。
