step属性无法可靠处理浮点微调是浏览器与ieee 754双精度模型共同决定的硬限制，所有异常表现（如0.3变0.30000000000000004、ios不显示小数键盘、chrome静默降级step）均源于此；唯一可靠方案是整数单位换算并全程用整数校验。
step 属性根本无法可靠处理浮点微调，这不是配置问题，而是浏览器+IEEE 754双精度模型共同决定的硬限制。你看到的“0.3”变成“0.30000000000000004”、iOS Safari 不显示小数键盘、Chrome 静默把 step="0.1" 当成 step="1"，全都是这个底层事实的自然表现。
为什么 step="0.1" 在多数浏览器里必然失败
0.1 在二进制浮点中实际存储为 ≈0.10000000000000000555。浏览器用这个近似值做模运算：(v - min) % step，结果几乎不可能精确为 0。表单提交时触发 validity.stepMismatch 是数学必然，不是 bug。Chrome 旧版本甚至会直接降级 step 值，Safari 则可能静默修正初始 value 导致 spinner 卡死。
- 手动输入 “0.3” → 提交报错，因为浏览器生成的合法序列是基于浮点累加，和你输的字符串不匹配
- 点击两次 ↑（
step="0.1"）→ 得到0.30000000000000004，这是 JS 浮点运算结果，不是浏览器“算错了” - 移动端 iOS Safari：number 键盘常不显示小数点，用户根本输不了 “0.1”，
step形同虚设
绕过浮点陷阱的唯一可靠路径：整数单位换算
金额、温度、浓度等所有对精度敏感的场景，必须放弃“元/℃/g”这类带小数的单位，改用整数基底。浏览器对整数 step 的支持是稳定、跨平台、无误差的。
- 金额：用“分”代替“元”，
min="0"、step="1"、value="199"表示 1.99 元 - 温度：若需 0.1℃ 精度，存为“十分之一摄氏度”，
min="-2730"（-273.0℃）、step="1" - 显示层用 JS 格式化：
(input.value / 100).toFixed(2)，但存储和校验全程用整数 - 避免混用：不要
min="0"+step="0.01"，而要统一写成min="0.00"、step="0.01"（某些浏览器对末尾零更敏感）
动态改 step 时 spinner 失灵的根本原因
浏览器不会因你改了 input.step = "0.25" 就自动重算当前 value 是否还在合法集合里。旧值大概率越界，导致拖不动、方向键跳变、松手回弹。
- 必须同步重置
value：input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - 优先用
input.setAttribute('step', '0.25')，比直接赋值input.step兼容性更好 - 连续切换步长时，加
requestAnimationFrame延迟重置，避免状态冲突 - 改完立刻调用
input.checkValidity()，必要时input.reportValidity()主动提示
step="any" 不是解药，而是退化开关
它只禁用步长校验，不解决浮点解析、valueAsNumber 截断、粘贴失真等问题。Safari ≤15.4 完全忽略，16.4+ 虽支持但 valueAsNumber 在某些场景返回 NaN；提交时 FormData 可能用 valueAsNumber 再转字符串，导致你看到的 “0.10000000000000001” 被替换成 “0.1”。
- 真正需要高精度时，应弃用
type="number"，改用type="text"+inputmode="decimal"+ 正则过滤 - 计算必须用
decimal.js或字符串拆解（如 BigInt 处理小数位），不能碰Number - 若坚持用
type="number"，至少加onchange="this.value = this.value.replace(/\.?0+$/, '')"清理末尾零（仅视觉）
最麻烦的从来不是怎么写 step，而是用户粘贴、拖拽滑块、用第三方输入法——这些行为完全绕过所有原生约束，step 一概不起作用。业务关键字段的精度保障，只能靠后端校验兜底，前端能做的只是降低误输概率。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
